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Abstract 


a rtificial Intelligence research involves the creation of extremely complex programs 
must possess the capability to introspect, learn, and improve their expertise. 
Any truly intelligent program must be able to create procedures and to modify them 
as it gathers information from its experience, [Sussman, 1975] produced such a system 
for a j "mini-world”; but truly intelligent programs must be considerably more complex. 
A cincial stepping stone in AI research is the development of a system which can 
unde rstand complex programs well enough to modify them. 

fThere is also a complexity barrier in the world of commercial software which is 
makjilg the cost of software production and maintenance prohibitive. Here too a 
systeip which is capable of understanding complex programs is a necessary step. The 
Programmer's Apprentice Project [Rich and Shrobe, 76] is attempting to develop an 
interactive programming tool which will help expert programmers deal with the 
complexity involved in engineering a large software system. 

This report describes REASON, the deductive component of the programmer’s 
apprentice. REASON is intended to help expert programmers in the process of 
evo/u ionary program design. REASON utilizes the engineering techniques of 
modelling, decomposition, and analysis by inspection to determine how modules 
interact to achieve the desired overall behavior of a program. REASON coordinates 
its various sources of knowledge by using a dependency-directed structure which 
recorls the justification for each deduction it makes. Once a program has been 
analyzed these justifications can be summarized into a teleological structure called a 
plan which helps the system understand the impact of a proposed program 
modi fication. 
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Chapter 1: The Importance of Program Understanding 

There is a fundamental distinction between running a program to do something 
and asking it to understand how it accomplishes that very same task. Even huge 
programs, like MACSYMA [Macsyina 1975], lack the ability to introspect, to examine 
their own procedures. But, lacking the ability to introspect, they also lack the ability 
to describe their own behavior, to modify their behavior, or to rationally plan the 
allocation of internal resources among competing tasks. To do such tasks, a program 
must understand itself. 

To understand itself a program must be able to understand programs. Artificial 
Intelligence programs are large and complex; they maintain large knowledge-bases, use 
multiple layers of interpreters, and frequently employ advanced control structures. 
This thesis attempts to formalize and represent some of the knowledge necessary to 
understand and explain such programs. It is incomplete and exploratory; more 
questions are raised than answered. However, I believe that several important 
advances are made, and hope that this work may serve as a bridge from past 
exploratory work of [Minsky, 1968], [McCarthy, 1968] and [Sussman, 1975] to future 
work on truly self-conscious systems such as proposed in [Doyle, 1978]. 

How can a program understand another program? In a step towards this, 
Sussman [Sussman, 1975] introduced a paradigm of how an intelligent computer 
program can acquire new skills. In this paradigm, a planning program first attempts 
to combine old ones procedures to form a "first order" approximation to a desired 
complex goal. This new procedure is then executed in a "careful mode", maintaining 
a record of the process. If one of several ire-defined kinds of "bugs" is recognized, 
the system attempts to analyze the bug and to debug its procedure so as to achieve 
the desired goal. 

Why is it not enough for a program just to understand its subject matter? What 
makes us want to have it "understand itself' as well? Even among the earliest works 
of AI, the issue of self-consciousness was raised. McCarthy’s proposal for the "Advice 
Taker" [McCarthy, 1968] was in essence a proposal to develop a system which 
understands its procedures well enough to be told how to employ them effectively, Le. 
to t^ke advice. Although many of McCarthy's original plans fell short of the mark 
there were many seminal ideas present as welL Similarly Minsky’s Matter, Mind and 
Models [Minsky, 1968] raised many of these issues. Sussman's Hacker was the first 
substantially detailed system to exhibit a serious approach to self-conscious acquisition 



2 The Importance of Program Understanding 
of knowledge. 

HACKER could be considered introspective in a limited sense. It knew what it 
had done, why it had done it, and what higher leve. goal each action was intended to 
achieve. Finally, it could examine the procedure it had coded and modify this 
procedure's code. 

But HA r KER was very limited in its expertise. It knew only about the blocks 
world, a miniworld with a one armed robot, a collection of blocks, and simple goals 
like building a tower. Such simplicity is crucial in the initial stages of scientific 
exploration; and HACKER remains an important milestone. However, to progress we 
must be capable of engineering a system which can understand procedures of 
complexity greater than those of HACKER. We need a system with greater expertise 
about programs! 

Follow-up work, unfortunately, has not developed very far in this direction, until 
recently. Goldstein [Goldstein, 1974], in his MYCROFT system attempted to present 
a more sophisticated taxonomy of procedures and bugs, but he also worked in a mini- 
world, the domain of graphics programs written by elementary school children. 
Sacerdoti [Sacerdoti, 1975] and Waldinger [Waldinger, 1977] both did further work on 
the simultaneous sub-goal problem, the most studied bug in HACKER's repertoire. 
However, none of these systems would meet the criterion of being experts at 
programming. 

This thesis will investigate the expertise needed to represent and understand AI 
programs. It will also present a reasoning system which knows what it is doing at 
each step and which uses this information in deciding what to do next This seems to 
me to be a basic step toward systems which are capable of modifying and changing 
their own procedures. [Doyle, 1978b] proposes to investigate such architecture 
thoroughly. My work should be seen as attacking some of the preliminary technical 
matters of the investigation; it is not a solution, but merely a stepping stone along the 
route to self-conscious systems. 

What is needed? Here is an example of an episode in which I described - to 
myself (and my tape recorder) - a plan for developing a certain system: 
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"This program is going to be doing a network type search. So the 
main feature of the implementation will be a Conniver-like data-base 
which in this case doesn't need contexts. There will be a demon feature 
where we will allow arbitrary number of patterns in each demoa An 
assertion will be a nested list structure; most of them will be simple. 
They'll describe the various kinds of relations. 

The data-base will take an assertion and regard it as a treelike 
structure, moving through the structure with the standard tree traversal 
until it reaches each terminal node. Each terminal will be indexed by a 
combination of its unique identifier (the MacLisp function Maknum) and 
its position in the list structure. Indexing means calculating a bucket to 
put the assertion into. Position is calculated by bit patterns which Til 
describe later. These two numbers are combined to form one number and 
this is used to calculate an index into the array. You do this for each 
terminal node and insert the assertion in each bucket you get The bucket 
will be in increasing order, so the insert will be an ordered-splice-ia" 

What expertise and knowledge are involved in understanding this description? 
Certainly one must know something about hash-tables, arrays, list structure, recursion 
etc. But what about these structures is it important to know? One has to reason 
abodt the behavior of such objects. Evidently, I do this by making references to 
standard kinds of procedures like oroereo-spiice-in and tree-traversal. What are these 
cliches? They seem to be more than just particular patterns of code, they are talked 
about as if they have a more abstract quality. How can we represent these "abstract 
proce lures"? What are the rules for their combination? Certainly any system which 
hopes to understand complex procedures must have answers to some of these questions. 

These tasks seem hard and complex and one might well wonder whether this 
research will produce a practical payoff somewhere in the not too distant future. I 
believe it will. Program understanding is crucial not only to AI, but to Computer 
Science and the computer industry as well. The rapidly growing power of 
comp Jtational hardware, has led to new demands for qualitatively more complex 
software. Commercial software production is reaching a "complexity barrier" 
[Wirjograd, 1973]. I believe that this barrier can only be escaped by using the 
computer as an intelligent and sophisticated support system for the expert programmer. 
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Section 1.1: The Problem of Program Maintenance 
Notes of A Beleaguered Systems Programmer 

Software and "software maintenance", has become the major expense of 
computation. As machines grew larger, faster, and cheaper, the programs which run 
on those machines have grown more ambitious and complex. But the programmer's 
tools for maintaining software have not kept pace with this growth. 

Why has "maintenance" become so important? The word is probably a misnomer 
which covers up the real issue: the evolutionary nature of the programmer - user 
relationship. Specifications for large systems are frequently incomplete and unclear; 
the user doesn't know exactly what he wants. Given fuzzy criteria the designer does 
the best he can, guessing here, making temporary choices there. 

Once a program reaches the stage of initial implementation new desiderata are 
almost always discovered: "This report should have these 3 extra fields; that one 
provides extraneous informatioa" New hardware becomes available resulting in 
changes in the requirements and new opportunities for improvements. In addition, the 
currently available features suggest new ones which could be implemented if only 
certain modifications were made 

So while the first implementation is running, work is started on adding features 
and reworking the last implementation Running experience reveals the existence of 
some new bugs which force additional redesign In this process the programmer again 
and again finds himself trying to remember whether it is safe to "smash the record" 
before it is stored, whether any module is using the second bit of the dispatch queue 
entry, etc. In general he is forced to consider all possible places which might be 
affected by any proposed change. Of course, one does what one can and version two 
eventually appears. 

At this point, the user and the programmer notice that there are new features, a 
brand new terminal which would allow real time interaction, and of course the 
inevitable bugs. So while version two is being run, the design evolves again; version 
three is laid out on the drawing board. And so on... 
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If the production of software is not to be halted by these problems, new help 
must be found. Computer science currently has two types of solutions; we shall 
propjcse a third. The first type of solution, disciplined programming, consists of 
improvements which avoid an automation of intelligent human skills. These include 
languages such as CLU [Liskov, et aL, 1977], ALPHARD [Wulf, et aL, 1976], etc. 
which attempt to reflect the programmer's intent in the code and to modularize the 
system so that dependencies are localized In this kind of programming methodology, 
erroh are minimized and some modifications of the software become simpler. Other 
effor s short of automation of human skills include the editors, debugging tools, and 
the like which systems like INTERLISP [Teitelman, 1975,77] and The Programmer's 
Woiil bench [Dolotta, 1976] have packaged into integrated language support facilities. 

At the other extreme is the proposal to automate the programming process itself, 
remp/ing the programmer from all but the most high-level design decisions. Automatic 
programming [Balzer, 1973], however, assumes a highly intelligent computer program 
whicm is skilled in the problem domain, algorithmic analysis, data structure selection, 
etc. Some success has been achieved [Green, 1977], [Barstow, 1977], 
[Maptia and Waldinger, 1977]. But a realistic appraisal would suggest that automatic 
programming systems will not be practically successful without the development of 
ver^ advanced AI techniques. 

[ would guess that no truly proficient automatic programming system can exist 
whicm is not capable of introspection and self-modification, Le. of skill acquisition, 
imp fo vement and development Once a deep theory of such skills is developed, it 
mig^i: become possible to build automatic programmers which, given advice from an 
expdi t human programmer, will improve their skills with practice. 

I will present here yet a third approach, called the Programmer's Apprentice 
[Rich and Shrobe, 1976], [Smith and Hewitt, 1975] which is intended to serve as an 
inte(l gent assistant to the expert programmer during a program's evolution. The 
apprentice has only limited skills: it is not yet expert in areas of program design or 
efficiency, but it does contain a large body of knowledge about programs and fairly 
sophisticated reasoning capabilities. 
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To use the apprentice one should not be required to provide such a large degree 
of details that the system would lose all practical utility. Instead I imagine the 
programmer providing the apprentice with approximately the same volume and type of 
information that is now supplied as background documentation and in-line 
commentary. Given this information the apprentice should be able to: 

(1) Modularize the code into appropriate segments each of which has logical coherence 
and an easily described behavior. 

(2) Derive an explanation of how the behavior of the segments interact to achieve the 
desired goals of the whole program. 

(3) Deduce which features of the program are crucial and which are gratuitous. 

(4) Relate this program to commonly used techniques of programming. 

(5) Help the programmer deride whether a proposed method could, in fact, achieves 
the desired goals and whether its sub-units can be fitted together in a coherent 
manner. 

(5) Detect coding errors as failures of the written code to correspond to the design. 

(6) Index this information for ease of use in program explanation The apprentice 
should be able to explain a program in high-level human-like terms. 

(7) Reason about the effect of proposed modifications to the code without having to 
analyze the entire program starting from scratch. 

Our apprentice system is set apart from verification systems like those of 
[Deutsch, 1973], [King, 1969], [Igarashi, et aL, 1975] by its central focus on the 
evolutionary character of the program design process. As I will explain later, this has 
led me away from a concern for "proving programs correct". Instead, I have been 
more interested in building a system which will interact with a programmer during the 
period of design evolution and which can converse with the programmer in terms 
which an experienced software engineer would find natural and familiar. The 
apprentice's goal is to interact with the programmer to develop reasonable designs 
which meet the engineer's criterion of "good enough" (as opposed the mathematicians 
criterion of provably correct). The apprentice should be able to analyze program 
designs at varying degrees of detail. During an initial interactive session it should be 
able to analyze the program sufficiently to catch obvious bugs. The information 
obtained by this analysis should be saved so that the apprentice can help assess the 
effects of changes which the programmer might want to make in the future. Finally, 
when the cost and time is merited the apprentice should be able to conduct a more 
thorough analysis and to verify properties of the program. 
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Section 1.2: An Imagined Scenario 
An Idealized Example of Using an Apprentice 


A typical interaction between the apprentice and a programmer building an 
associative retrieval system would look something like the following (Note: as usual the 
use <|f English dialogue is a convenient fiction whose only purpose is to make the 
presentation more comprehensible. Natural language understanding and generation are 
beyond the scope of this work.) A similar scenario was presented as a "wish list" in 
[Floyji, 1971]; at the end of the scenario I will indicate how much of my wish list is 
met the current system and its foreseeable development 


Programmer: I want to make an associative retrieval system which will be something 
like the one in CONNIVER. It will store each assertion in each bucket hashed to by 
one of its leaf nodes. Tm going to start by coding the insert routine for this data¬ 
base! Here's the code: 


(defim 


insert (assertion table size) 

(do ((assert assertion (cdr assert)) 

(index 1 (plus 1 (times index 2))) 

( car-assert nil)) 

((Null assert)) 

(setq car-assert (car assert)) 

(cond 

((atom car-assert) 

(bucket-insert array (hash car-assert index size) assertion)) 
(t (insert car-assert table size))))) 


Note: The code above is written in MACLISP. The do function used 
above is an iteration construct The first s-expression following the do is a 
set of clauses controlling the iteration. Each clause begins with a variable 
I name which is bound locally by the do. If there is an s-expression 
following the variable name then the variable is initialized to have the 
value of this expression; otherwise the variable is initialized to nil. If there 
is a third s-expression in the clause, then each time the loop is repeated 
the variable is assigned the value of this expression. If there are several 
loop variables, the assignments of their values is done in parallel. 
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The second s-expression following the do is a list of s-expressions. 

The first of these is a termination test which is evaluated at the beginning 
of each loop repetitioa If this s-expression evaluates to a non-nil value, 
execution of the loop terminates. The following s-expressions in the 
termination clause are evaluated; the value of the last s-expression is the 
value of the whole do expression. 

All succeeding s-expressions are the body of the loop and are executed 
each time the loop is repeated. A return expression in the body of the 
loop terminates loop execution, return takes one argument The value of 
this expression is the value of the whole loop . 

Apprentice: I'm not sure I understand this code completely. It appears that you're 
doing a tree-traversal through the assertion and filtering for the terminal nodes which 
are the atoms. But I don't understand what the purpose of index is, nor do I 
understand why hash takes index as an argument The hash I know about takes a 
single object and an array-range and computes an index of that array. 

Programmer In this system hash takes two arguments: (1) An atom which appears in 
the assertion; (2) A number, called index, which indicates the position of the atom in 
the assertion, given that the assertion is viewed as a tree. If the same atom appears 
twice in the assertion then it will have more than one index; this allows us to 
distinguish the two occurrences. 

Apprentice: I still don't understand. Explain the numbering scheme to me please. 

Programmer: The idea is that every node, except for the root, is the immediate child 
of some other node. Number the root node 1 and then each child is numbered as 
follows: If the node is the left child of its parent, its number is twice its parent's; if 
it is the right child of its parent its number is twice its parent's plus 1. 

Apprentice: The way you wrote the code when you make the recursive call for the 
car (i.e. the left child when the assertion is viewed as a tree) you don't pass the index 
of the current node as an argument, so it starts counting from 1 agaia 

Programmer: You're right Til have to change that; that means that the routine will 
have to take the index as an argument, which means that there should be an 
initialization function to call from the outside. Til recode it: 
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(defun insert-1 (assertion table size index) 

(do ((assert assertion (cdr assert)) 

(index index (plus 1 (times index 2))) 

(car-assert nil)) 

((Null assert)) 

(setq car-assert (car assert)) 

(cond 

((atom car-assert) 

(bucket-insert array (hash car-assert index size) 
assertion)) 

(t (insert-1 car-assert table size (times index 2 )))))) 

(defun insert (assertion table size) 

(insert-1 assertion table size 1)) 

AppMntice: One further questioa I assume, given its name, that bucket-insert inserts 
its tiird argument into the bucket indexed by its second argument You're inserting 
assertion on each call, which is not the same object all the time. My understanding of 
this type of hash-table is that an assertion should be in each bucket that its terminals 
hash to. But when you make the recursive call for the left nodes, assertion becomes 
the c irrent sub-tree of the assertion. 

| 

Programmer You’re right again. I should make the whole assertion an argument to 
the procedure as welL Can you make that change? 

App|< rntice: Yes, consider it done. How about the bucket-insert routine; would you like 
to design that now? 

Programmer: OK. In this design, buckets will be ordered lists of assertions, bucket- 
insert will fetch the bucket indexed by its second argument and then do a list-insert. 
This will be the standard trailing-pointer-enumeration which tests each item to see if 
its imque-identifier is larger than that of the assertion. Til use LISPs maknum to 
implement the unique identifier. When the first larger member of the list is found, 
ril splice in the new assertioa 

Apprentice: I understand the design, but there is a mistake. If the new assertion is 
smaller than any element, then it can't be spliced ia 

Pro^fammen In that case, cons it onto the front of the list 


For (pomplex Program Understanding 





10 The Importance of Program Understanding 

Apprentice: That won't work either, since you want the assertion to be a member of 
the bucket indexed by the hash you've calculated. But if you just cons this new 
assertion onto the front of the list it won't be in the list pointed to by the table. 
The item of the table in that position will still be the old list which is the cdr of the 
one which contains the new item. 

Programmer: OK. If this case is reached we'll not only cons the element on, but we'll 
also store this new list in the appropriate position of the table. 

Apprentice: The design now is correct 

Programmer: Here's the code: 


(defun bucket-insert (array index item) 

(do ((current (arraycall array index)(cdr current)) 

(previous nil current) 

(unique-id (maknum item))) 

((null current) 

(cond ((null previous) 

(array-store array index (list Item))) 

(t (rplacd previous (list item))))) 

(cond 

((> (maknum (car current)) unique-id) 

(cond ((null previous) 

(arraystore array index (cons item current))) 

(t (rplacd previous (cons item current)))) 

(return t))))) 

Programmer: Now I'd like to do the lookup. I just realized that lookup is very similar to 
insert. It also does a tree-traversal through the list structure, calculating indices and 
fetching buckets. I think that this ought to be modularized so that there will only be 
one place where this indexing is done. I guess what Fd like to do is write a 
subroutine called index which takes an assertion, the table and the size and the returns 
the list of buckets which this assertion indexes to. 

Apprentice: The current insert routine is a tree-traversal which produces a sequence 
of indices which are handed to bucket-insert. Each occurrence of bucket-insert fetches 
the bucket You can re-arrange things so that index will do the tree-traversal, 
producing the sequence of indices; each of these is fed to bucket-fetch to get the 
bucket, and each of these can then be fed to a list-accumulator to produce a list of 
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buckets. 


Here's the code: 


(defun index-1 (assertion table size index bucket-list) 

(do ((assert assertion (cdr assert)) 

(index index (plus 1 (times index 2))) 

(car-assert nil)) 

((Null assert) bucket-list) 

(setq car-assert (car assert)) 

(cond 

((atom car-assert) 

(setq bucket-list 

(cons (arraycall array 

(hash car-assert index size)) 
bucket-list))) 

(t (setq bucket-list 

(index-1 car-assert table size 

(times index 2) bucket-list)))))) 


(defun index (assertion table size) 

(index-1 assertion table size 1 nil)) 


App 
I do| 
hand 
bucke|t 
index 


Prog^rnimen Can you fix insert to call index, rather than doing the indexing itself? 


Entice: It would seem so. Since index produces a list of all the correct buckets, if 
a standard list-enumeration of these Til produce a sequence of buckets to be 
ed one at a time to bucket-insert. So the general plan is still the same. But, 
[insert will have to be changed since it now expects its input to be an array 
not a bucket 


Programmer: Change it to make it expect the bucket 

Apprentice: Now you've got problems. In the special case where the item being 
inserted is smaller than any presently in the bucket, we had to store the new bucket 
back into the table. But bucket-insert in this new version doesn't have the index of 
the bucket 

Programmer Oh well! Actually, I wanted to change the representation of the buckets 
a little anyhow. I want the first item of the bucket to be a count field and then the 
list or members to be the rest of the list I think if you'll check, it will turn out that 
this ilemoves the problem since the item to be inserted will always have to come after 
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the count field; you can always do this by side-effect The list*insert routine will 
have to be initialized differently, starting with the previous pointer pointing at the 
whole bucket including the count field and the current pointer pointing at the cdr of 
this list which is the part with all the items in it 

Apprentice: Yes, that will work, except that I can't prove that the table will always 
have such a structure in each slot Arrays are initialized to nil, not buckets as you 
just described them. 

Programmer: I will write an initialization routine later which will set up the table to 
have empty buckets in each slot 

Apprentice: What should be in the count field of the bucket? There is no code to 
maintain it yet 

... and so on 

[Note: this dialogue was extracted from a transcript of several coding sessions]. 

This scenario clearly is more ambitious than anything currently implemented. In 
particular, the language and discourse expertise implicit in this scenario are not even 
part of my current research goals. However, the basic facilities in this system are 
now under development The apprentice system I have shown consists of four main 
facilities. First, the programmer proposes designs which the apprentice checks for 
logical consistency. In chapter 7 I show an example of such an analysis which was 
conducted by the first implementation of REASON. In the case where a design is 
incorrect, however, the scenario shows REASON framing high-level descriptions of the 
problem. This facility is not yet developed. 

The second facility shown in the scenario is the ability to determine whether the 

actual code corresponds to the design. This facility is not part of REASON at all; in 

[Rich & Shrobe, 1976] we described an initial design of a recognition system which 
could conduct such an analysis. 

The third facility shown in the scenario is the use of pre-proven fragments to 

analyze a program's behavior. This is coupled with the use of temporal collections to 

segment the system into these fragments. Chapters 8 and 9 present a detailed 
formalism for this kind of analysis. [Waters, 1978] reports on an implemented system 
which conducts such an analysis for mathematical FORTRAN programs. The use of 
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plan fragments to guide the logical analysis is not yet implemented in my system. 


he final facility is shown in reasoning about program modifications. This is 
discu$;ed in chapter 13. My current system is only part of the way to being able to 
handty such reasoning. As the system makes deductions it records the logical 
depeft iencies used in each step. Furthermore, once it has conducted a complete proof 
it afljlyzes these into a summarized form called purpose links. These, together with 
the complete proof are the basis for further reasoning about modification. However, 
the techniques for using these representations are still being developed. 


Throughout the scenario, the apprentice exhibits considerable expertise about data 
struct ares and side effects. In Chapters 11 and 12 I discuss the techniques used to 
conduct such an analysis. The basic framework shown in these chapters is now well 
worked out, but is still in the process of implementation. The earlier version of 
REASON could conduct similar side effect analysis, but was far less robust and 
flexib 


In general, the reader should remember that the above scenario is a wish list and 
that the remainder of this thesis is a progress report on the research required to 
implement the facilities of the wish list 
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Section 1.3: The Research Content of This Thesis 

The apprentice represents a practical, medium term research goal in which many 
of the issues of program .understanding can be explored The representation of 
programs, the ability to understand the underlying logic of a program and to reason 
about the effect of program modifications are crucial prerequisites to the development 
of a self-conscious system capable of serious skill acquisition. I will develop in this 
thesis a representation called plans for the logical structure of programs and a 
reasoning system which follows a discipline of explicit representation of its control 
strategies. This will allow the system to examine its own control state and to chose 
what to do next based on that examination 

Throughout the scenario above we saw the apprentice and the programmer 
referring to a shared body of knowledge about standard program structure. The 
apprentice talked about tree-traversal , list-accumulation, filtering certain elements. 
The middle section of this document will develop the plan formalism for representing 
such notions and will present examples of some useful standard plans. Influenced by 
the work in [Waters, 1977] this formalism has been extended from that in 
[Rich and Shrobe, 1976] to allow plan fragments which produce and consume 
sequences of objects distributed in time. The importance of this notion can be seen 
in the scenario above where the apprentice develops the code for index from that for 
insert. Having done this the apprentice notices that index produces a list of buckets 
which is the same sequence of values as that produced by the internal tree-traversal 
and bucket-fetch fragments which were internal to index. When grouped appropriately, 
a call to index followed by a standard list-enumeration is identical to the internal 
fragments of index. In the last section of the thesis I will consider how to analyze the 
effects of such program modifications and how to maintain consistency as procedures 
evolve through the design process. I will show how the analysis of programs into plan 
fragments can greatly reduce the complexity of understanding modifications. 

The programs which I present in this thesis involve side-effects on complex and 
shared structures. Analyzing this kind of program is a very tedious process which 
people simplify using many heuristics. In chapters 11 and 12 I will show how the 
reasoning system can analyze side-effects at varying levels of detail which correspond 
to the levels which people seem to use. This will allow the system to develop an 
understanding of what the program is intended to do, before it is forced to determine 
what it actually does in all the possible "screw-ball" cases. The system is capable of 
going back and being more careful in its analysis, using the information from the first 
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analysis to guide the second The use of dependency information and non-monotonic 
logic [Doyle, 1978] to conduct side-effect analysis is unique to this thesis. 

The work reported on here is part of an ongoing project to develop a working 
Programmer's Apprentice. Charles Rich and I began in this work in 1974; many of 
the jc.eas presented here were developed jointly. It is hard to identify all those places 
in this thesis which have been influenced by Rich's [Rich, 1977] ideas. The 
Programmer's Apprentice project was later joined by Richard Waters who used many 
of our initial ideas to analyze numerical FORTRAN programs [Waters, 1976]. Waters 
founr^ it very convenient to think of loops as being built up by a series of Plan 
Build ng Methods. In his view a loop consists of a nucleus which produces a sequence 
of values. Embedded in this nucleus are various augmentations which consume the 
sequence of values produced by the nucleus. Augmentations can be made to operate 
on a restricted sequence by including a filter to eliminate certain elements from 
conskleratioa 

Waters' ideas find their way into this thesis as a more general notion of 
temporal-collections which may serve as the outputs and inputs of segments. Any 
recursive program can be viewed in at least two ways, involving two distinct 
segme ntations: One of these called the temporal-viewpoint involves a cascade of 
segn}< nts passing such temporal collections; the other, called the surface-viewpoint, , is 
simply an aggregation of the code into modules. Some features of the program are 
mad£ clear by the temporal viewpoint while others are seen more easily in the surface 
viewpoint 

The program REASON reported on in this thesis has gone through several 
incarnations. As part of my earlier work with Rich, an initial version of REASON 
was designed and reported on in our Master’s Thesis [Rich and Shrobe, 1976]. That 
version was completely coded and worked as reported. However, the earlier version 
was rather cumbersome and ill-suited to the recognition tasks for which it was 
intended. During the later part of the development period of the first version of 
REASON [Stallman and Sussman, 1976] introduced the use of dependency networks in 
their electronic circuit analysis program EL The dependency network was then 
extended and built into a separate package called the Truth Maintenance System in 
[Doyle, 1978]. Although the first version of REASON maintained dependencies, it did 
not have a truth maintenance system which used these to any advantage. Doyle and 
other>, however, built a simple problem solving language, called AMORD 
[DeKleer, et al., 1977] which did interact with the TMS. 
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The current version of REASON is being developed as a program written in a 
variant of AMORD. I have had enough experience with the first implementation and 
the partially completed new version to report on this work with confidence. 

In the chapters 14 and 15, I will attempt to evaluate this admittedly partial work 
and to compare it to other, more developed systems for program understanding. I 
hope that the reader will find the tedium of working through this document rewarded 
by at least an occasional glimpse of something promising. 
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hapter 2: An Engineering Theory of Evolutionary Design 

jjrhe scenario of the last chapter emphasizes the evolutionary character of the 
process. I believe that the key to supporting such an evolutionary interaction is 
^|evelopment of powerful techniques for program analysis. Analysis is the process 
omposing a program into coherent modules such that the behavior of the whole 
artifh^t can be understood in terms of the behavior of its parts. 


desigif 
the 

of dfclt 


The dominant form of analysis in current computer science research is the 
Floyd-Hoare verification techniques, especially as developed by [Igarashi, et 
al, In this technique the basic unit of decomposition is the programming 

langiuge primitive whose behavior is specified by axioms written in Hoare's logic. 
Each such axiom provides a method for transforming a post-condition of a 
progi-imming language primitive into a pre-condition (or vice-versa). Verification 
usually proceeds by stating a pre-condition and a post-condition for an entire program. 
The^e are combined using a process known as Verification Condition Generation 
(VC<t). VCG passes the post-condition back over each language primitive of the 
progfim in turn; the statement arrived at when the modified predicate is finally passed 
over the first primitive of the program has the property that it must be true on 
program entrance if the original post-condition is to be true on program exit Finally, 
an implication is formed from the pre-condition of the whole program and this new 
statement If this implication can be proven, then the program must exhibit the 
behavior specified by the pre- and post-conditions. 


tiling 


Given the attention paid to verification techniques in recent years, one might 


that they are sufficiently powerful to help manage the problems of evolutionary 
desigh. I feel that such a conclusion is unwarranted. Program proving techniques will 
play an important, but limited role in supporting incremental design and evolutionary 
programming. It is my feeling that the techniques now in existence have been 
designed with a particular kind of program - namely algorithms - in mind and that 
there are a large number of distinctions between such programs and the software 
systems which I am interested in. This difference of concern has lead to a difference 


in pe 


spective and methodology which underlies this entire document 


1. Much of this material was originally written as part of a proposal to the National 
Sciep^e Foundation. I acknowledge and appreciate the extensive editing by Charles 


Rich 


and Richard Waters which went into those sections. 
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Section 2.1: Type of Programs — Algorithms vs. Systems 

We can identify two different kinds of programs: algorithms and systems which 
differ along a number of dimensions. Each kind of program is valid and important to 
computer science, but they present different demands and requirements. I believe that 
program proving is most useful and necessary for the domain of algorithms while the 
techniques I introduce in this document are more useful for the analysis of systems. 

Typically, an algorithm is a relatively short program which can be precisely and 
concisely specified. Specifications for an algorithms often are much shorter than the 
program text For example, the Euclidean GCD algorithm occupies about 7 lines of 
code in any recursive language; its specification is of about the same length: the 
answer divides both inputs and it also is divisible by any other common divisor of the 
inputs. The Knuth-Morris-Pratt or the Boyer-Moore string matching algorithms 
occupy roughly 100 lines of code but have a very short specification: the answer 
returned is the position of the first string in the text which matches the input pattern. 

A second feature characterizing algorithms is that they exhibit a clever underlying 
logic which requires proof. The intricacies of either of the string matchers mentioned 
above would lead one to doubt whether they worked unless a rigorous proof were 
presented. Indeed, the cleverness underlying any particular algorithm makes its code 
quite different than of other algorithms. Thus, one finds few familiar cliche's in the 
code. Instead one must work hard to find an explanation for the function of each 
line. In addition, since algorithms are meant to be used as components of other 
programs, it is crucial that they be known to be correct; a single mistake could have 
thousands of repercussions. 

Algorithms are built to satisfy a precisely stated specification which has general 
utility. The specification is not subject to change or reinterpretation. An algorithm 
is not an evolutionary program. Euclid's and Pingala's algorithms have survived in 
essentially unchanged form for more than a millennium. 

A final point about an algorithm is that it frequently represents an extremely 
optimized method for achieving a very common task. This optimization is achieved 
through clever and often obscure techniques. But in the case of an algorithm this is 
allowable and even desirable. The algorithm is published with an explanation; it is not 
intended to be modified and therefore intricacy is appropriate if it leads to an 
improvement over previous techniques. 
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Dne might be inclined to think of a system as nothing more than a large 
collection of algorithms. However, the description above should make it clear that the 
whole is more than just the sum of its parts. Each of the characterizing aspects of 
algorithms are in fact untrue of systems. Software systems are large programs with 
specifications and other related documentation exceeding the size of the code by an 
order of magnitude. The specifications are not crisp, well defined, or permanent 
Indeed, they often are tied to social and institutional practices which change for 
reasbis having nothing to do with computation. Financial and management systems 
are dependent on tax codes, business practices, etc. Military related systems depend 
on the arms technology and defense strategies of the world powers. When specifying 
systems which function within such a nexus, it is impossible to state precisely what is 
to be done; one instead states some criteria which must be met and others which are 
suggestive of less crucial but desired behavior. In any event these criteria change, and 
the s /stem is forced to evolve to meet the new criteria. 

Although much can be done with methodologies for requirements definition, 
experience in the military and in industry suggests that the effect of such methodology 
has i significant but limited impact It is an empirically undeniable fact that 
specifications are never completely elaborated and that they evolve with the life of a 
system. Even in the most careful of system designs the product passes through many 
iterations of design and coding before something acceptable is developed. In the next 
seetjen I will present an argument for why this must be the case. 

Systems also differ from algorithms in the degree to which they involve clever 
and intricate logic. Typically a system of programs is made up of a large number of 
relatively small modules, each of which involves routine and mundane code. There is 
a vocabulary of cliche's out of which such code is built and the experienced 
programmer can analyze such routine coding patterns by inspectioa Occasionally 
some hing idiosyncratic is thrown in but even these are usually simple to understand. 
Even at higher levels of the system, sub-modules are combined in routine ways. 
Verification of such modules would be conducted mainly as a method of isolating 
coding mistakes such as fencepost errors and typos. 

The complexity of a system does not primarily arise from the use of locally 
intricate strategies, but rather from the sheer number of interactions between modules. 
Thes<! make it difficult to assess the effect of a proposed change to the system since 
each module may enter into purposeful relationships with many others. Systems tend 
to reach a point where the volume of these interactions overwhelm unaided human 
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abilities to manage the complexity. Once this point is reached changes to the system 
produce more harm than good. Rather than continuing to evolve, the system is 
frozen and a new system is commissioned. 

In summary, we may distinguish between algorithms and systems along two major 
dimensions. Algorithms are permanent, almost mathematical objects, which are not 
subject to frequent modification of either code or specification Systems are 
impermanent, evolutionary programs of little mathematical interest The complexity of 
an algorithm is largely due to the use of locally intricate and clever strategies; the 
complexity of a system is due primarily to the sheer volume and number of 
interactions between modules. 

These distinctions lead one to see the need for different kinds of automated 
design tools. The designer of algorithms needs the use of proof checkers, theorem 
provers and verification systems. While these serve a useful role for the systems 
designer as well, they are not his bread and butter. Instead he needs tools to help 
him modify current designs to meet incrementally new requirements. Given the size 
of a software system, one cannot tolerate the delay and expense of a completely new 
analysis every time such an evolutionary modification is desired One instead requires 
incremental processing in which a small change in the design should require only a 
small amount of reprocessing to achieve an adequate analysis. 

Even if a program can be proven correct, and even if this can be done in an 
incremental fashion, there is still a problem. The sheer volume of information 
developed during the proof of a software system renders the information useless unless 
the analysis structures the information so that it is comprehensible to a humaa When 
a system designer sets out to make a modification, only a tiny fraction of the 
information is actually relevant; the system designer needs tools which can produce 
just this information and no more. My work is directed towards the production of 
such tools. 


Section 2.2: What Characterizes Evolutionary Change? 

As we saw in the scenario of the last chapter, the user repeatedly proposes 
designs and then debugs these designs until he is convinced that they achieve the 
desired goaL In some cases he even goes so far as to reorganize the program, 
breaking down some module boundaries and erecting new ones in their stead For 
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exant )le, the code for indexing an assertion is extracted from the insert code, modified 
and ihen made into a module which is called from the lookup routine. At another 
point the user decides to change the structure of the buckets. 

In each of these cases the proposed modifications have ramifications which reach 
beypr d the boundaries of any modules apparent in the code, yet the programmers 
cleaijl / thinks of them as incremental or evolutionary changes. I wish to contrast 
thes^ evolutionary changes with the situation in which the programmer cannot 
accommodate whatever change he is considering within his current conceptualization of 
the system and so redesigns "from scratch". In an evolutionary change, the main 
parameters of the current design are left as they were; only some small set of changes 
is needed to achieve the desired goal. In redesign, the entire structure of a program 
is blocked out anew. 

Sow can we tell which of these categories a change will fall in? This is a key 
ques^ on since I want my system to be prepared to handle those changes which an 
experienced programmer will think of as evolutionary. The received wisdom in 
programming methodology is the principle of the modularization. This principle 
(whi^ti is the computer science version of "a place for everything and everything in its 
plac^ ) suggests that if module boundaries are carefully arranged so as to localize each 
desig 1 choice to a single module then all evolutionary changes can be handled by local 
charges to a small number of modules. However, there are clearly evolutionary 
changes which do not fit into this paradigm. As I have already mentioned, the 
scenario contains examples of the programmer making modifications in which the 
module boundaries are rearranged, yet these changes are clearly thought of as 
evolutionary. 

The principle of modularization suggests that evolutionary changes are those 
which are local to a module. Although, I believe that this notion is overly rigid, I do 
beliele that the notion of locality within a decomposition is the crucial idea which 
characterizes those changes which can be treated as evolutionary modifications. In the 
next several sections I will develop the following thesis: Engineering analysis consists of 
the tjse of partially accurate models to allow a system to be decomposed into multiple, 
overlapping, tangled hierarchies. A modification will be perceived as evolutionary 
if there is at least one decomposition such that within its segmentation 
structure the effect of the modification appears local. 
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Section 2.3: Why Is Evolutionary Design Necessary? 

Why don't we just design correct programs to begin with and dispense with the 
expense of design iterations, debugging, and evoluticn? There are those, for example 
[Dijkstra, 1976] who believe that such a fault-free methodology is both desirable and 
possible. In this view, one would start with specifications for a program's behavior 
and refine these in a top-down step-wise manner until a correct program had been 
reached. It is claimed that by carefully stating the invariants (for example on loops) 
before they are coded, one can assure a high degree of reliability for the code 
produced. This may be summarized by saying that one should have a proof of 
correctness in mind when one begins to code. 

As far as this goes it presents little to argue with; however the methodology 
provides little concrete guidance as to how one should develop the design and proof of 
correctness to begin with. I suspect that if this approach is suitable at all, it is only 
useful for the creation and implementation of algorithms. As I have observed, the 
process of algorithm development is quite different than that used for the design of 
large software systems. Algorithms are the result of months (or years) or research; 
when a researcher has the insight for a new algorithm, he can then proceed through a 
top down design process in which his insight is elaborated into a design for the 
coding. This can and should include specifications for the sub-modules of the 
algorithm. Such careful specification and elaboration of the algorithm’s design can 
then lead to a correct or nearly correct coding of the program. 

The design and construction of large software systems is quite different I have 
already observed that systems are evolutionary by nature. One reason for this is 
external; the design of a system often depends on social and institutional practices 
which change quite frequently. However, there is also an internal, cognitive reason 
why systems are designed incrementally, namely that the cognitive complexity of the 
task allows no other approach. The designing of a software system is, in my view, a 
form of problem solving not very different from that used in a conventional 
engineering disciplines such as electrical engineering or even in common sense 
reasoning. The overriding goal of such forms of reasoning is to manage and reduce 
the complexity of the design task to the point where human cognitive powers are 
adequate to produce a reasonable solution Much of Artificial Intelligence research on 
problem solving has consisted of the development of paradigms which account for this 
type of reasoning. These center around the related ideas of decomposition, modeling, 
and debugging as intrinsic parts of the planning process. 
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Common sense reasoning and engineering problem solving share a need to limit 
complexity of the planning space. In both these domains if all possibly relevant 
> were to be considered at once they would overwhelm human cognitive capacity, 
rather than trying to guarantee a perfect answer from the start, one works for 
wer which is close enough and then modifies this to fit the actual needs. If 
cjoes not take this approach but rather insists on perfection from the start, the 
ng process would stall out at the first step. 


4s 


The goal of a problem solver is to piece together a collection of actions which 
will achieve a specified set of goals. Typically, the problem solver only has to achieve 
thes6 goals given that certain conditions hold in the initial world state. This collection 
of actions is called a "plan" and consists of several forms of information: First, a set 
of stib-steps and their behavioral descriptions; Second, a set of constraints on the 
ordef ng of sub-step execution; Third a means of propagating information between the 
sub-? eps. Finally, and most importantly, the plan includes an explanation of how the 
segments interact to achieve the desired goals. Notice, however, that the sub-steps 
are not necessarily primitive actions; the problem solver may have to attempt their 
solution recursively. 

The earliest planning systems used the paradigm of heuristic search in which the 
probl em solver repeatedly tries to take a single step from its current world state to 
another state which is hopefully closer to the goaL This approach was used in 
systems like GPS [Newell &et aL, 1959] and STRIPS [Fikes & Nilsson, 1971]; 


how£ 

Min? 


yer, it was found to lack sufficient power for task of even moderate complexity, 
jky’s suggestion of the notion of "islands" [Minsky, 1961], however, led to a new 


paradigm which was partially embedded in the PLANNER language [Hewitt, 1972]. 

The key insight in PLANNER is that a reasonably knowledgeable problem solver 
will often recognize the form of the answer; having done so it can propose a partially 
instantiated plan immediately. Such plans are used as the starting point of the 
solution with the problem solver recursively attempting to synthesize a plan for the 
sub-?:eps by recognize the form of their answer. This method of problem solving 
(calle j Planning by Recognition of The Form of The Answer ) was formalized in the 
Planner programming language and was improved upon in its descendants Conniver 
and |<|)A4. 
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Within particular domains of expertise the paradigm of Planning by Recognition 
of the form of the answer is facilitated by the development of an engineering 
vocabulary which conveniently captures the abstract form of most problems. In 
particular, within programming domains one often can identify an "intermediate 
vocabulary" of programming abstractions which constitute the building blocks out of 
which a large percentage of the known techniques of particular domains are built 

When viewed from the perspective of analysis, the Recognition Paradigm takes 
the form of Analysis by Inspectioa As a planning paradigm Recognition decomposes 
the problem into a pattern of sub-steps by recognizing the form of the problem. As 
an analytic technique, Inspection reconstructs the form of the problem by recognizing 
the pattern of sub-steps in the device. Both of these rely on the existence of a 
powerful body of "standard plans" which reflect the common ways of achieving those 
goals whose form is understood. The existence of this body of knowledge reduces the 
heavy cognitive cost of heuristic search to the much less burdensome price of searching 
a "plan library". 

However, even the paradigm of Planning by Recognition does not adequately 
model human problem solving behavior on very complex tasks. Yet another paradigm, 
that of Planning In an Abstraction Space [Sacerdoti, 1973] must be added. In this 
paradigm we add to the above notions a further idea, that of modeling. An 
abstraction space is a model of the real world in which some important details arc 
intentionally (or otherwise) omitted Planning is first attempted in such an 
Abstraction Space. If a completely developed plan is formed in the abstraction space, 
then the process advances to an attempt to modify the plan to function in a less 
abstract space. 

Notice that this recursion of planning and refining in a hierarchy of abstraction 
spaces is a different recursion than the recursive invocation of the problem solver on 
the subgoals. In the later recursion the metric is the size of the task, in the former it 
is the accuracy of the modeling space. An important consequence of this paradigm is 
that as one proceeds through increasingly accurate models, a new plan is formed by 
incremental modification of the plan produced by the preceding stage. One 
implementation of this paradigm was embodied in the Abstrips program 
[Sacerdoti, 1973], a descendant of Strips. Comparisons between the two programs 
showed that Abstrips could outperform Strips by a factor of 4; as the problems grew 
harder the difference between the two systems became even more pronounced. 
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\bstrips, however, had only a very weak method of modeling the real world; its 
only abstraction consisted of weakening the preconditions of its built-in operations. 
Thu^ its only debugging technique consisted of splicing set-up steps into the abstract 
plam 

Susstnan's Hacker also identified a second reason for the indispensability of 
debugging. Suppose that a problem solver is presented with a goal for which it has no 
plan n its library. In this case, the problem solver should attempt to reformulate the 
proqhm statement so that it can be decomposed into parts whose solutions can be 
four^c by Recognition. However, when this decomposition is made there is always the 
possibility of destructive interference between the plans for the various sub-parts. 
Furthermore, until one has found plans for each sub-goal separately, one cannot tell 
whether they interact Inherently one is faced with the need to debug the total 
solu^bn to remove destructive interference between the sub-plans. 

[ believe that these paradigms explain the mechanisms used by people to manage 
the [complexity of planning in large and complex domains. One first constructs a 
men^kl model of the domain in which many details have been omitted This produces 
a search space of considerably smaller size in which it is computationally feasible to 
derive a plaa This plan, like every other, has a "proof of correctness" (or an 
expiration of how it achieves its goals); however, this "proof of correctness" might 
actu^ly be incorrect since it depends upon assumptions in the model which may 
violate facts in the real world. Nevertheless, these fictions in the modeling process are 
extremely valuable; without them the complexity of the problem would prevent one 
froib building a plan at all This "almost right" plan is refined by developing a more 
accurate model of the situation and then using the current "proof of correctness" to 
guide the debugging process. As the Abstrips program indicated, developing the plan 
in an abstraction space and then debugging it is a computationally cheaper option than 
attempting to develop a correct plan directly. It is for this cognitive reason that 
soft^ire must be designed in an incremental, evolutionary manner. 

If computer based design aids are to be of assistance to software system 
designers, they must take cognizance of the nature of the design process which I have 
outlined. Design aids must satisfy two criteria: First, they must be able to reason 
aboijl abstract plans and their hierarchical structure Given any world model the 
design aid must be able to check whether a proposed design will achieve its goal. 
Since the plan development process is a recursive one in which the sub-steps of a plan 
are themselves candidates for plan synthesis, the design aid must be able to understand 
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a proposed plan even if its sub-steps have not yet been designed However, the 
constraints imposed on these sub-steps must be remembered so that they can be 
checked when the plans for the sub-steps are formulated. 

The second major criterion that such a system must meet is its ability to deal 
with plan editing, modification, and debugging. A plan is initially developed to work 
under the assumptions of the abstract model; when these assumptions are revised to 
more closely correspond to the real environment or when the environment itself 
changes, the logic of the original plan must be examined to see what dependencies are 
no longer valid. Thus, the design aid must be a dependency based reasoning system 
capable of sophisticated belief revision processing. 

The problem of managing evolutionary design faces engineers in all disciplines. 
But it is particularly acute in computer science for two reasons. First, computer 
science is a young field without the maturity and experience of civil, mechanical or 
electrical engineering. In a sense there is as yet no engineering discipline. Secondly, 
software engineers deal with a peculiar problem in that the major constraints one deals 
with are not physical but social. Since social phenomena are more transient than 
physical laws, the modeling process in software system design is unusually hard and 
inaccurate. This suggests that software engineering should look to the more mature 
engineering sciences which have developed sophisticated techniques for managing the 
complexity of their fields. We will see that the paradigms of problem solving 
developed in Artificial Intelligence research have their counterparts within these mature 
engineering domains. 


Section 2.4: What Do Engineers Do? 

One might think that engineering is mainly concerned with the optimization of 
numerical parameters within physical systems. If so, computer science would have 
little to gain from the study of the methodologies used in engineering. Indeed, 
engineers do conduct such activity, but this is only a small part of what engineering is 
about Engineering is mainly concerned with limiting the complexity of analysis. 
[Bose & Stevens, 1965] give the following account of the engineering exploit: 
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A physical problem is never analyzed exactly. This is a consequence 
both of our inability to describe a physical situation completely and of the 
increasing complexity of the analysis as greater accuracy is demanded. A 
problem that involves events in the real world is always approached by 
making simplifying assumptions that hold only approximately, thereby 
forming a model of the events under study. The problem then reduces to 
that of analyzing the modeL If the assumptions by means of which the 
physical situation was reduced to the model are reasonable, then our 
analysis should produce results that correspond to observed events, and the 
same type of analysis should be useful in predicting the behavior for other 
similar physical situations. 


have identified three areas of technique which seem to be common to all 
sering disciplines and which provide fruitful starting points for the development 
similar technology for software engineering. These areas are (i) The construction 
[most accurate" models which reduce the complexity of a pure physical analysis 
producing tolerable inaccuracies; (ii) The decomposition of complex systems into 
sevefjil possibly overlapping almost hierarchical organizations in which aspects of the 
behavior of the whole artifact may be simply inferred from the behavior of the 
sub-systems, (iii) The development of a vocabulary of characteristically useful 

intermediate constructs which allow analysis by inspectioa 

Engineering models reduce the complexity of an analysis by omitting details not 
nt to the task at hand. Electrical engineers, for example, use models of 
stors which describe their behavior accurately enough given that the transistor is 
to be operating within a certain range of frequencies and power. Such models 
however, produce grossly incorrect result when used outside the range of their 
lability. Thus, in analyzing a system more than one model of a particular 

j}:>nent may be used, each model explaining the components behavior within some 
rangje of operatioa 



part$ 


fn the domain of programming one also needs to model the behavior of various 
of a system. Richard Waters and I have developed a modeling technique, called 



temporal abstraction, in which some aspects of a system's behavior are made quite 
to understand. For example recursive programs can be temporally abstracted into 
tpler non-recursive programs in which sequences of data are communicated in 
parallel between sub-segments. I will give an overview of this technique later in this 
chapter and will present in thoroughly in Chapter 8. In the temporal model of the 
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program some ordering constraints are omitted Thus, a second model corresponding 
more closely to the surface features of a program is also needed 

Engineering modeling makes a trade off between accuracy and ease of analysis. 
In order to be able to make the analysis the engineer is willing to introduce "tolerable 
inaccuracies". Engineers don't have to be perfectly correct, only "close enough". 
However, when a model is used inappropriately conclusions can be reached which 
exceed the threshold of tolerable errors. One must, therefore, maintain a record of 
how each conclusion was reached so that a debugging process can be invoked to 
identify the source of the error and to substitute a more appropriate modeL I will 
present a program reasoning system which uses the Truth Maintenance System 
[Doyle, 1978] to maintain this information. This allows our system to incrementally 
reanalyze a program when its original models were found to be too sweeping in their 
omission of details. 

A second area of technique common to many engineering disciplines is the 
decomposition of larger systems into a (possibly overlapping) hierarchy of sub-systems. 
Each sub-system is given a simple description which describes only those aspects of its 
behavior which are relevant to other sub-systems. We may then regard the whole 
artifact as a loosely coupled network in which the behavior of the whole system may 
be deduced from the descriptions of each subsystem. Often, however, it is necessary 
to decompose a system in more • than one way in order to derive convenient 
explanations for all of its behavior. In electrical circuit analysis, for example, one 
makes one decomposition to facilitate the DC analysis and a second decomposition for 
the AC analysis. A single component may be present in both decompositions playing 
different roles depending on which decomposition it is viewed from. 

Engineering decomposition techniques include some of the most elegant analytical 
methods of all science. Norton and Thevenin's equivalence theorems for electrical 
networks allow one to decompose any electrical network into a collection of 
two-terminal devices which are accurately modeled by a single source and a single 
impedance. 

Perhaps because decomposition is such a basic strategy, it is also a relatively 
advanced technique in computer science. The use of sub-routines as procedural 
abstractions which are described by their input-output behavior is well established. 
Data abstraction techniques allow a second type of decomposition. Typically, these 
techniques are embodied in the features of a programming language. While I 


Dependency Directed Reasoning 



2.4 What Do Engineers Do? 29 


recognize the significance of such efforts I also note a drawback. Analysis frequently 
reqqi'es multiple decompositions of a single system; however, a programming language 
requires that the system be represented by a single decomposition which is most often 
correlated with the imperative structure of the system. 

The third major type of engineering methodology involves techniques to facilitate 
analysis by inspection. For each design problem an engineer must establish the form 
of the answer. Frequently the most powerful aspects of an engineering discipline exist 
to facilitate analysis by inspection. In electrical engineering, for example, the notion 
of Complex impedance allows the inspection techniques which were first developed for 
resistive circuits to be applied to circuits involving inductances and capacitances as 
well Thus, a single set of abstract forms, such as the notion of a voltage divider, 
can | )e applied to a much broader class of circuits. Without this technique, the far 
more complicated methods of differential equations would be required 

Given such techniques it becomes possible to catalogue the various forms of 
problems and their typical solutions. This is done by developing a craft or engineering 
discipline with an associated vocabulary of macroscopic constructs. Although there are 
virtually an infinite number of combinations of the primitive objects of any discipline, 
most of these are not useful. However, a much smaller set of combinations turn out 
to have sweeping power within particular domains. These form the "standard plans" 
of a domain; they are the terms of the engineering vocabulary. Lisp programmers, for 
exarpple, have a relatively rich vocabulary including ideas like "cdring down a list", 
"tree traversal", "searching a sequence of values", "consing up an answer", etc. In 
chapter 9, I will discuss the process of analysis by inspection; chapter 10 will present a 
brief catalogue of some useful data structures and chapter 13 (in passing) will present 
a description of some typical procedural plans. 

An engineering approach works with such higher level notions since such 
descriptions reduce the complexity of making sense of a device. The various 
techniques which have been mentioned so far interact to allow an analysis to 
decdi npose the system into components whose behavior conveniently explains the 
behavior of the whole. For example, the construction of a temporal model allows the 
syst ^\n to be decomposed in a manner which separates the process of generating a 
collection of objects from the process which consumes these objects. Once this 
decomposition is performed, it frequently becomes trivial to analyze the components by 
inspection. In this case, we have an interaction between modeling, decomposition and 
recog nitioa In chapters 12 and 13 I will show another modeling technique which 
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similarly reduces the complexity caused by allowing side effects on shared data 
structures. 

By using these techniques, it becomes possible to impose a very rich structure on 
a program. This structure includes: several decompositions with mappings between 
them, simplifying modeling assumptions, and recognition mappings which explain how a 
particular fragment corresponds to a prototype from the plan library. This vast 
quantity of information is unified by the use of a dependency based reasoning system 
which records all logical dependencies which it discovers in a special data base. These 
dependencies may then be consulted at any time to discover the possible ramifications 
of any proposed modification. My thesis is that the techniques outlined above 
facilitate an analysis in which any change which a programmer would regard as 
evolutionary is localized within the module boundaries of at least one decomposition. 
Once a modification is localized within some decomposition the task of assessing the 
impact of the change becomes cognitively manageable since the decomposition renders 
irrelevant all but a small fraction of the information. 

In the remainder of this chapter I will present a somewhat more detailed 
overview of the techniques which I have developed along these lines. 


Section 2.5 1 Plans and Teleology 

Whether designing or analyzing a device, an engineer must have a 
representational system within which it is possible to utilize and coordinate information 
derived through the techniques described above. In most engineering disciplines there 
is a notion of the "design plan" which forms a skeleton around which all of this 
information is arranged. Of all the issues discussed so far, the design plan is the one 
least well addressed by other current work in computer science 

In traditional engineering or software engineering, the behavior of a device can 
be described in two ways. Some properties of a device are independent of its context 
of use These properties constitute the intrinsic description of the device The LISP 
function append can be described intrinsically by its input-output behavior of returning 
the concatenation of its arguments. A device may also be described by its role or 
purpose in the plan for a larger mechanism. This is its extrinsic description, append, 
for example, may be used to produce the union of two disjoint sets represented as 
lists. 
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A single part may have several extrinsic descriptions corresponding to multiple 
need$| that it satisfies in the larger mechanism. A copying garbage collector such as 
[Minsky, 1963] uses the same array of space as both the destination for reclaimed cells 
and A; a queue in a breadth first tree traversal of the space of used cells. There may 
also fee several plans for a given device, describing its structure in different dimensions. 
In this situation, each part has the potential for one or more roles in each plan. 

I The essence of understanding a mechanism is knowing the purposes of each part 
nvolves building a description of the mechanism which matches each part with 
es in the appropriate plans. Each role in each plan must be filled by some part 
! mechanism and the intrinsic properties of that part must satisfy the extrinsic 
ties of its roles. 

Certain plans or plan fragments can appear as part of the plans for many 
different devices. For example, the depth first tree traversal plan fragment appears in 
several of the modules coded in the scenario. However, understanding the teleological 
struct .ire of a plan fragment (which may be very difficult) need only happen once. 
Any properties of the plan fragment which can be discovered, are known to hold 
wherfeyer the plan is used. These common plan fragments serve as an "engineering 
vocab dary". 

Section 2.6: Representing Plans 

£ upporting a programmer during design evolution requires the apprentice to 
reasdr about program designs before they have been committed to code. This requires 
the Apprentice to have a program representation which is independent of the choice of 
progik mming language. In our Master Thesis, Charles Rich and I 
[Rich & Shrobe, 1976] presented such a representation for abstract programs which we 
called plans. We reasoned that programs like other engineered artifacts should have a 
simple underlying conceptual structure consisting of a decomposition into parts and 
meahs for communication between these parts. When we specialized this observation 
to programs, we observed that the functions performed by programming language 
primitives fall into two categories which might be called "actions" and "connective 
tissue’*. Actions are modules which operate on a set of input data objects, yielding a 
set of new and modified output objects. Connective tissue arranges the flow of data 
and Control between the actions. 
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We then designed a formalism based on this observation- The formalism consists 
of segments, control-flow links, data-flow links, and abstract data objects. An 
abstract program is represented as a set of segments connected by data and 
control-flow links which specify how information propagates between tne segments and 
which partially constrain the execution of the sub-segments. Segments are actions; 
they are used to represent the sub-steps of the program. Segments may be nested one 
within the other yielding a super-segment and sub-segment relationship. 

Each segment has a set of local names for its input object and a second set of 
local names for its output objects; these names may be thought of as "ports". A 
Data-flow link is a directed connection between the ports of two segments. Typically 
the connection is made between the output port of one sub-segment and the input 
port of a second sub-segment, indicating the output object named by the first 
sub-segment's port will flow to the input port of the second sub-segment A dataflow 
link may also connect the input port of a super-segment to the input port of one of 
its sub-segments; finally a dataflow link may connect the output port of a sub-segment 
to the output port of its super-segment Data-flow links imply an ordering of 
execution; a segment which terminates a data flow link cannot begin execution until 
the datum is available at the initiating port of the segment Control-flow links are 
directed connections between two segments, implying that the first segment must 
terminate before the second segment may begin A plan consisting of segments and 
these two types of flow links may not completely constrain the ordering of 
sub-segment execution. Thus, as observed in [Sacerdoti, 1975] plans are non-linear. 
They are inherently a two dimensional structure the linearization of which accounts 
for most of the complication of language design. 

The plan formalism is intended to represent designs; however, these designs 
eventually turn into code in some particular language. A technique called surface flow 
analysis was developed to bride the gap between the two forms of analysis. Primitives 
such as if-then-else, while, variables assignment, argument passing, eta which are 
concerned solely with ordering and communication are translated into data and control 
flow links. Other primitives such as arithmetic operations, cons, car, cor, eta are 
translated into segments. Such surface flow analyzers have been developed for LISP 
[Rich & Shrobe, 1976] and FORTRAN [Waters, 1978]. 
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During design a segment represents one step of a problem decomposition. 
Therefore, a means is required to specify abstractly what a segment does. This is 
don£ by stating the segment’s specs which consists of: (i) a set of input names (ii) a set 
of preconditions which must hold immediately prior to program execution (iii) A set of 
output names (iv) A set of post-conditions which are guaranteed to hold immediately 
following the segment's execution. Alternatively, one can specify what a segment does 
by seating its plan, i.e. by presenting its decomposition into sub-segments. 
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The plan formalism can be interpreted by a symbolic evaluator which is in many 
s quite similar to a LISP interpreter. However, the symbolic interpreter uses 
or symbolic data as input. Therefore, it must explore all control paths. In 
on it must use a reasoning system to deduce whether the pre-conditions of each 
nt are satisfied. The symbolic evaluator is described in chapter 6. 


I will often present plans using a graphical formalism. The symbols in this 
forntalisin are shown below. 


Segments may have a conditional structure which is stated by breaking the 
segments up into cases. Each case is applicable under certain circumstances which are 
in the segment's specs. Control flow links can be attached to a particular case 
segment; the segment which terminates such a link is executed only if the 
ular case is applicable. This creates mutually exclusive control paths which can 
ited by a join segment 
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As an example of how this formalism is used consider a programmer designing 
the symbol table for a block-structured language like ALGOL-6G. A hash table 
might be used to store and retrieve the symbols efficiently. Each symbol is given a 
new entry in the table when it is first encountered; as the symbol is encountered in 
new blocks, the entry is marked with the block- id of the new block. 

To achieve a simple action such as marking a symbol with a block identifier 
(block- io) several other operations such as hash-table-lookup, sorted-insert, rplaca, etc. are 
called upon. These sub-actions interact to achieve the desired goal of having the 
symbol table indicate that the specified symbol is defined in the indicated block. This 
is done as follows: First, hash-table-lookup is called to see if the symbol is defined in 
the table. If it is, the entry returned by hash-table-lookup is passed to ordered- insert 
which inserts the block-id of the specified block into the entry’s list of block-id's. If 
the symbol has no entry in the table, new-entry is called to build a new hash-table 
entry; the new entry is created with a block-id list including exactly the specified block- 
id. This new entry is passed to hash-table-insert, which inserts it into the table. 

This can be diagrammed as follows: 
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Plan Diagram For Mark Present Operation 


hash-1 able-lookup has a case structure; it performs a test and splits control into several 
paths, depending on the result of the test The two control paths are rejoined by the 
join segment join-table. Notice that crossed lines show the flow of control between 
segnji mts; normal lines shows the flow of specific data objects. 

Notice that many of the modules used to build mark-present will eventually have 
internal structure of their own. ordered-insert, for example, will probably consist of a 
search-loop, a cons, and a rplacd. The hash-table routines will involve steps such a hash, 
bucket-fetch, etc. Thus, the structure given above is a layered one nesting boxes within 
boxes until one finally reaches programming language primitives. 

Each segment in the plan above can be thought of as promising that certain 
conditions will hold after its execution as long as its preconditions are satisfied. Such 
sets <f>f promises are stated using the specs formalism. As mentioned above, specs have 
four clauses. Two of these, inputs and outputs provide a list of input and output 
names which are bound to the actual inputs of the segment The other two clauses 
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are the expect and insert clauses which state the pre-conditions and the post-conditions 
of the segment A typical set of specs looks like: 


(defspecs fetch-bucket 

(Inputs: table-1 index-1) 

(Expect: (object-type table-1 hash-table) 

(index table-1 index-1)) 

(Outputs: bucket-1) 

(Assert: (bucket table-1 index-1 bucket-1))) 

which states that, given a well-formed hash-table and an index of that table, fetch- 
bucket will return the bucket of the table indexed by the input index-1. 

Notice that since the specs for a segment only refer to the segment's I/O 
behavior, it can apply to any segment which accomplishes the behavior required 
Thus, a specs is a type applying to different algorithms for the same functioa The 
square root specs describe a program using Newton's method as well as one which uses 
the halving method. It is also important to understand that the specs formalism is a 
local and intrinsic description, saying what a segment does, not why it does it Specs 
have no notion of method or purpose within them. 

However, for an engineered device to function properly, it is necessary that the 
pattern of interactions between sub-modules guarantees that every module's 
expectations be satisfied at the time of its invocation Further, the pattern of 
interactions must guarantee that the desired behavior of the whole device will result 
from the behaviors of the parts. It is only within this more global and extrinsic 
description that a notion of purpose is found. For example, in a hashing system we 
can talk about the purpose of the hashing step- it computes the index of the bucket in 
which the desired object should be found, eliminating the need to search through 
other buckets which cannot contain the object Similarly, in a hash-table-insert routine 
the purpose of the list-insert routine is to splice the element into the appropriate 
bucket so that it will be a member of the table. 

A plan consists of a pattern of sub-segments connected together by data and 
control flow links. Two kinds of requirements are found in a plan. First there are 
the requirements that each sub-segment's expect conditions must be satisfied; this is 
called a pre-requisite requirement Second is the requirement that the overall goals of 
the main segment must be satisfied; this is called an achieve requirement The first of 
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requirements is indicated by the expect clauses of the sub-segment's specs; the 
is indicated by the assert clauses of the main segment's specs. If the plan 
kents a reasonable design then it is possible to show how the behavior of the sub- 
;nts interact to satisfy these requirements. It is possible to summarize such an 
ent so that it only refers to basic units of description, the spec clauses of those 
Segments involved in guaranteeing that the requirement is satisfied. These 
arized arguments are called purpose links: 


Hi 


Consider the following diagram for a hash-table-insert routine, hash is called with 
the lable and the object to be inserted as arguments and calculates an index of the 
tablp Fetch bucket is called with this index and the table, producing a bucket of the 
tablb; the bucket must be a linked list Finally, the bucket and the object are passed 
to list-insert which side-effects the list, inserting the object into the list This causes 
a derived side effect to the table; since one of its parts is side effected, the table is as 
wel| The updated table is returned as an output of hash-table-insert The pre-requisite 
and ichieve conditions are indicated on the side of the diagram. 
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Diagram For Hash-Table Insert Routine 

We can look at the specs of the sub-segments to see how the purpose links arc 
developed. The specs for hash are: 


(defspecs hash 

(inputs: the-table the-object) 

(expect: (object-type the-table hash-table)) 

(outputs: the-index) 

(assert: (object-type the-index number) 

(index the-table the-index))) 

We have already seen the specs for fetch-bucket above. Notice that the second assert 
clause of hash, implies that the second expect clause of fetch-bucket is satisfied Now 
let us look at the specs for hash-table-insert 

(defspecs hash-table-insert 
(inputs: an-object the-table) 

(expect: (object-type the-table hash-table)) 

(outputs: ((the-updated-table id-to the-table))) 

(assert: (side-effect the-table (member the-updated-table an-object)))) 

The use of id-to in an outputs clause indicates that the output the-updated-table is the 
same object as the input the-table. The side-effect assert clause indicates that the-table 
is changed to include an-object as a member. If we look at the specs for list-insert 
we will see how this clause is satisfied. 


(defspecs list-insert 

(inputs: an-object the-list) 

(expect: (object-type the-list list)) 

(outputs: ((the-updated-11st id-to the-list))) 

(assert: (side-effect the-list (member the-updated-1 ist an-object)))) 

Clearly, the assert clause of list-insert indicates that the assert of hash-table-insert is 
satisfied; however, it does so only in interaction with the assert clauses of fetch-bucket 
and hash which indicate that an-object is inserted in the list into which it hashes. The 
satisfaction of the assert clause of hash-table-insert depends on assert clauses from each 
of these sub-segments. 


Dependency Directed Reasoning 




2.6 Representing Plans 39 


We call these logical links between sub-segment behavior purpose-links ; those links 
whitjlji explain how a sub-module's expectations are met are called pre-requisite links, 
thosfe which explain how the overall intentions of the main segment are met are called 
achie -e links. The pattern of purpose links, together with the data- and control-flow 
links, and the various sub-segment's specs is what we term a plan Plans play a 
cental role in the work of the programmer's apprentice because they explain the 
teleological structure of the program: the reason why each module is present and the 
logid of how the modules' configuration achieves the overall goal. 

The addition of purpose links transforms the plan formalism from an abstract 
programming language to a design representation which includes not only a set of 
actions to be performed but also a statement of their teleological structure. Since the 
sub-s;gments of a plan may be specified at a high level of abstraction it turns out 
that the plan formalism can easily represent abstract teleological structures. As I've 
men^ oned, there is a craft discipline among programmer's consisting of a repertoire of 
standard methods for achieving certain types of goals. There are standard ways to 
trave se a tree or a list structure, and standard methods for accumulating items into a 
set These standard methods can be conveniently represented as standard plans , using 
the abstraction powers of the plan formalism to capture the significant generalities of 
a programming domain. The plan formalism has the added virtue of representing 
thes^ techniques in a manner which is independent of the particular programming 
language being used. 

E -et me explain this a bit more before going on. Suppose I had a set of objects 
ented by some data structure and I wished to build a a collection of all 
members of this data structure which satisfy some criterion. One standard technique 
for accomplishing this is what I term the filtered-accumulation plan. This plan 
consists of three sub-plans. The first is an enumeration plan which generates the 
elem < nts of the original data-structure; if this data structure is a list then this plan 
would have a familiar pattern of "cdring down" the list; if the data structure is a 
binary tree, the enumerator would have the structure of "car cdr" recursion. The 

second sub-plan is a filter plan which tests the elements produced by the first 
sub-f lan selecting those which satisfy the criterion. The final sub-plan is an 
accumulation plan which builds a new data structure containing those elements which 
passed through the filter. If the final data structure is to be a list, this sub-plan 
would have the familiar pattern of "consing up" a list 
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Now consider the code for two versions of this idea In the first version (written 
in ALGOL) the original and final data structure are arrays; the second version (in 
LISP) uses a binary tree and a list 


integer array A[0:100], B[0:100]; 
integer i, j ; 
j :* 0 

for i := 0 step 1 until 100 do 
if Criterion (A[i]) 
then begin 

j := j + 1; B[j] :* A[i] 
end 


(defun fil-acc (tree) (fil-acc-1 tree nil)) 

(defun fil-acc-1 (tree acc) 

(cond ((Criterion (value tree)) (setq acc (cons (value tree) acc)))) 

(cond ((terminal tree) acc) 

(t (fil-acc-1 (left tree) 

(fil-acc-1 (right tree) acc))))) 

Even ignoring the language differences, there is clearly quite a bit of difference 
between the two programs, yet I have already claimed that they are actually instances 
of the same general technique, filtered-accumulation. The plan formalism captures 
this generality using temporal abstraction Temporal abstraction looks at the history of 
the computation, grouping together occurrences of segments of like type. For 
example, in the LISP program there are recursive invocations of fil-acc-i producing 
several occurrences of segments of this type. Similarly in the ALGOL program the 
loop executes repeatedly producing several occurrences of the loop. Temporal 
Abstraction aggregates all these occurrences into a single new, abstract segment which 
is called the enumerator Each of the occurrence within the enumerator produces an 
output object In the ALGOL program the output is the contents of the ith array 
slot; in the LISP program, the output is the value part of the current tree node: 
These outputs are aggregated into a new, abstract data structure called a temporal 
collection (since the objects are produced one by one, the collection exists across time, 
rather than as a single unified data-structure). 
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We may similarly observe that in each program there are repeated occurrences of 
Criterion test. These may be aggregated into the filter sub-segment We may 
that each program has a repeated accumulation step. In the ALGOL program 
bonsists of the two steps of adding one to j and then storing a quantity into the 


Jth ? lot of the array b; in the LISP program the accumulation is performed by the 
Again, the repeated occurrences of these steps can be aggregated into a segment 
this is done, we can notice that the filter segment will contain a number of 
ical test segments which have no data flow between them. However, from the 
successful case of each test segment there is a data flow to a sub-segment of the 
accu nidation plan. Internally, the accumulation plan is a cascade of identical set- 
accu mulators ,, each of which takes two inputs: (1) a set which is input from the 
previous accumulator and (2) a new element; the accumulator produces a new set 
whici includes all the previous elements plus the new one. The set output by the 
final accumulator is the output of the whole filtered-accumulation plan. From this 
vievMoint both programs have the following common structure. 
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Notice that at this level of description we have left many features unspecified. 
For example, we have not said what type of object is input to the enumerator nor 
how it works internally. In spite of this, we do know that this pattern of interactions 
(i.e. this plan) produces a set whose members are a subset of the elements contained 
in the enumerated object Furthermore, we know that this subset consists of exactly 
those members w’hich satisfy the criterion of the filter. Indeed, this general pattern of 
segments is so common that one ought to recognize it where it occurs and immediately 
infer that the output is exactly this subset Languages such as CLU 
[Liskov, 1974,77] and ALPHARD [Wulf, 1974,76] have introduced iterators and 
generators to make it easier to capture these and similar notions. Temporal 
abstraction will be discussed in detail in chapters 8 and 9. 

The Apprentice approach to program understanding is distinct from the approach 
of program verification systems like [King, 1969], [Deutsch, 1973], [Igarashi 
et aL, 1975]. In the Apprentice, although we require the usual logical techniques we 
do not focus our attention on the primitives of the programming language in an 
attempt to write axioms for their behavior. Instead, we abstract away from the 
language as rapidly as possible, building up higher levels of abstraction until a standard 
plan such as filtered accumulation can be recognized 

The apprentice has several distinct components which are involved in 
understanding a program. The first of these is the library of standard programming 
techniques, called the plan-library. Plans, as we have seen are stated in a language 
involving data- and control-flow, rather than the primitives of any particular 
programming languages. Thus, a surface-flow-analyzer must translate the source code 
of a program into the internal language of data- and control-flow. This 
representation is grouped into segments in an attempt to recognize the various standard 
plans present in the program. Work on recognition is reported on in [Waters, 1978] 
where plan-building-methods provide initial clues to segmentation and in 
[Rich, 1977,78] where a plan-library is used to guide a heuristic component of the 
recognition system. 
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The recognition systems, however, must call on a reasoning system from time to 
time to see whether their proposed recognition of the code is feasible. In later 
chapters as I present the deductive component more carefully we will see the use of a 
task-agenda and an explicit recording of dependencies. These are the methods by 
whicn the deductive component communicates with other parts of the system. 


whic 


The deductive component of the system plays a second role in the apprentice 
H I refer to as plan-verification. The apprentice requires a large library of 


standard plans whose properties have already been analyzed and recorded While it is 
oretical possibility that such complete analyses could be produced by hand, in 
practical terms this is prohibitive. Instead, the deductive component of the system is 


used 
In 


to show that a plan (stated at any level of abstraction) satisfies certain properties, 
this use, REASON is presented with a plan-diagram consisting of data- and 


conti ol-flow links and specifications for the sub-segments used in the diagram. It is 
then asked to show that certain properties hold; often it is useful to give REASON a 
set c f lemmas to be proven first which will structure the proof and make it more 
corpf rehensible. REASON is also allowed to ask for help if it feels that it is getting 
lost As the system develops the proof, it records all its deductions. These are then 
summarized into the pre-requisite and achieve links of the plan which is filed in the 


plan 


library as a new standard plan. 


In the typical interaction with the apprentice, as seen in the scenario, the 
progi ammer first develops a design for a segment of code, using the plan library as a 
shared vocabulary of high-level building blocks. As these pieces are woven together, 
the ; pprentice checks that pre-conditions of each segment are satisfied and warns the 
progi ammer of design bugs if any precondition is violated. When the programmer 
believes that a total plan has been formulated he asks the apprentice to check whether 
this plan does achieve the intended goals. 


throv 


In general the programmer will not begin to code a segment until he has gone 

[ >h this design-checking protocol with the apprentice. Having completed the 
at the level of abstract plans, however, he goes on to write the code. It is at 
oint that the surface analyzer and the recognition components are called on to 
match the code and the already verified plan. If the alignment is made, then the 
progi ammer proceeds knowing that his program accomplishes the things which he had 
askecj the apprentice to check. 
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Frequently, however, the programmer may find it more convenient to write the 
code without going through the design protocoL Under these conditions the 
apprentice will have weaker clues and will have to interact with the programmer more 
often, asking for specifications and other hints to guide its analysis. In any event, 
once the analysis is complete the apprentice will have constructed a recognition 
mapping between the code and the plan for the segment; in addition most of this plan 
will have pointers back to plan fragments from the library. Thus, the apprentice can 
explain the code using the high-level vocabulary of the library. Furthermore, the 
apprentice will have developed and written in the notebook a complete explanation of 
the intermodule dependencies, giving it the ability to examine how changes to one of 
the sub-segments will affect the behavior of the whole program. 

In summary, the plan of an engineered device is a set of logical connections 
between the conceptual descriptions of sub-modules, the descriptions of implementation 
strategy, and the overall intentions for the device being engineered These logical 
steps explain how each module of the overall device contributes to the higher level 
conceptualization as well as why each sub-module is capable of functioning. The lack 
of such a logical connection in a proposed device would indicate a conceptual failure 
or design bug. Since any engineering discipline builds up a repertoire of standard 
plans, understanding an engineered device is largely a matter of recognizing which 
standard plans are used and how they are interfaced to achieve their intended goals. 

Given that modules of a device may themselves be conceptual constructs with 
internal structure, plans provide an abstracting mechanism describing the structure of 
the device at a level appropriate to the task at hand. Plans also allow one to describe 
and reason about the behavior of incompletely designed devices, since a module’s net 
behavioral specifications may be used within a larger plan even if there is as yet no 
internal plan to accomplish the behavior of the sub-module. 


Dependency Directed Reasoning 



2.7 Plans in Maintenance and Explanation 45 


Section 2 .71 Plans in Maintenance and Explanation 

Plans, as outlined above, give a teleological description of program behavior, 
abstracted to a level of description which is convenient to the programmer. It is a 
rather trivial matter to generate explanations of a program from a plan. Since plans 
contain more information than does the program itself, such explanations will be richer 
than a mere recitation of the code. 


As 1 


My goal, however, is to understand and support the process of program evolution, 
have noted, plans capture the relationship between program design choices, 
abstract modularization, and overall intentions. In doing this, they localize the effects 
of a change in design strategy, and specify the teleological requirements which must be 
satisfied in any modification of the design. 

As a simple case, consider a hash-table insert routine which has been 
implemented using ordered linked-list buckets with a count field. The code for such a 
progiam might be: 


(defun insert (item) 

(insert-in-bucket (table (hash (key-part item))) item)) 

(defun insert-in-bucket (bucket item) 

(do ((previous-list bucket (edr previous-list)) 

(current-list (edr bucket) (edr current-list))) 

((null current-1 ist)(rplacd previous-1ist (list item))) 
(and (greater-than (car current-list) item) 

(rplacd previous-list (cons item current-list)))) 
(rplaca bucket (1+ (car bucket)))) 


Since 


puppose that for space efficiency we decide to change to a rehashing scheme, 
this change is strictly a design issue dealing with buckets, the plan tells us that 


the overall structure of the insert module itself will not have to change, but that the 

InSCf'-^d-Riirkpt moHnl<=> QC U^aII QC /'Am mu m iL. i — J..I * _ » 


-In-Bucket module as well as the communication between the two modules might 
requji e change. It further tells us that the last line (Le. the rplaca which bumps the 

court ) is no longer relevant At first glance one might guess that this is all the help 
one < ould get 
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However, the plan library reveals that there is more structure in common 
between the old and new designs. In the library, plans and data-structures are 
organized into (tangled) hierarchies where objects lower in the hierarchy inherit 
properties from those above them. In both implementations of a hash-table we have 
that the buckets are linear-objects\ furthermore, we have a generalized version of the 
search-loop , called linear-search-loop which can search any linear-object such as lists or 
arrays. The more specific versions of linear-search-loop differ only where the choice 
of representation for the particular linear-object is relevant 

This difference appears in the bump, exhaustion, and termination steps. In the re¬ 
hash scheme, bump is the re-hash operator and successful termination of the search is 
indicated by a special marker (si. a as nil) indicating that a slot is free. Exhaustion 
of the search might be indicated by the re-hash routine returning a negative number. 

An item is made a member of a bucket in the re-hash scheme by inserting it in the 
array. 

In the linked-list version, bump is the cdr operation; objects are selected by car, 
exhaustion of the list is indicated by the presence of nil Successful location of a 
place to insert the object is indicated by the presence of a larger element in the next 
position. Using this information, the system guides the programmer to the following 
new program (I will discuss this idea further in chapter 13): 


(defun insert (item) 

(insert-in-bucket (hash (key-part item)) Item)) 

(defun insert-in-bucket (initial-slot item) 

(do ((slot initial-slot (rehash slot))) 

((minusp slot)(error ’no-slots-left)) 

(and 

(null (table slot))(store (table slot) item)))) 


Typically, the apprentice builds more than one viewpoint of the program during 
the recognition process. During program modification, one or another of these 
viewpoints might provide a perspective from which the effect of the modification 
appears quite localized. In any event, since the apprentice has a complete record of 
all the logical dependencies, it can easily evaluate whether any proposed modification 
can damage a desired property. 
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Section 2.8: Dependency Directed Reasoning 

A plan may be thought of as an abstract program coupled with a logical analysis. 
However, it is important to note that this logical analysis need not necessarily be a 
"proof' in the sense of a guarantee of correctness. REASON is capable of 
cond acting logical arguments which range from the informal or "common sense" to the 
rigofaus. In many cases the plan for a program will only contain a "common sense" 
or t ngineering analysis which is inadequate to guarantee correctness under all 
cond tions, but which is good enough for purposes of explaining its teleological 
structure. When necessary, REASON can be asked to verify certain modules and can 
carry this out with full rigor. We often observe experts making an analysis in exactly 
this vay: First they conduct a common sense analysis to explicate certain facts and to 
establish a framework of understanding; once this is accomplished the framework 
gukhs a more formal analysis, keeping it from getting lost in a sea of combinatorics. 
It would be desirable for REASON to be able to do something like this. 

Another desideratum is than an incremental change in the program should 
nec$j sitate only incremental changes in the analysis of the program. To partially meet 
thes^ desiderata REASON was designed as a dependency based system. In a 
dep^i idency based system every new assertion entered into the data base is 
accdi npanied by a justification stating which other assertions form the logical support 
for the new one. The justification itself is an object which the system can inspect 
and nanipulate. 

Assertions in the reasoning system have one of two statuses: in or out. An in 
asser ion is one which is believed. An out assertion is one not currently believed A 
special module called the Truth Maintenance System (TMS) [Doyle 1978] is responsible 
for guaranteeing that all assertions with valid reasons to be believed are in and all 
asser ions lack valid justifications are out. 

REASON has several uses for dependency based reasoning: management of 
abstract models for programs, analysis of program modifications and hypothetical 
reasoning during theorem proving. In chapter 12 I will discuss the use of dependency 
bas^cj reasoning in the the analysis of side-effects. In this situation, REASON first 
conducts a simple analysis assuming that the degree of sharing between complex data 
structures is limited. Various desired properties of the program are then proven, 
undej' this assumption. Sometimes such a cursory analysis is sufficient However, 
whed a more careful exploration is desired, the assumption can be removed and 
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replaced by a more cautious assumption or by no assumption at alL The TMS uses 
the dependencies to determine what conclusions remain valid under the new 
assumptions. In many cases, some of the important properties of the program do not 
depend on the assumption and remain in However, if some property does in fact 
depend on the assumption it will go out indicating that the original proof is not still 
valid under the conditions of sharing. A more detail proof can then be attempted. 

I will now turn to the detailed presentation of the techniques used in REASON. 
In chapter 3 I will first discuss the reasoning system per se; chapter 4 will introduce 
the task agenda and the system's method of explicit controL Chapter 5 will present 
the program description techniques in detail. Chapter 6 presents the symbolic 
interpreter for the plan formalism and chapter 7 gives an example of how this can be 
used in program verification This chapter is quite tedious and can skipped without 
loss of continuity. Chapters 8 and 9 detail the techniques of temporal abstraction and 
its use in analysis by inspection In chapter 10 a language for describing data 
structures is introduced along with a catalogue of data descriptions which REASON 
uses. These descriptions are used during program analysis and recognition and are 
important to the material which follows on the analysis of side effects* However 
Chapter 10 need not be read very carefully to understand the material which follows* 
Chapter 11 presents my techniques for reasoning about side effects by making 
simplifying assumptions. This material is extremely novel and quite distinct from 
verification literature on the same subject Chapter 12 is a brief discussion of some 
concepts which can be used to make the ideas of chapter 11 more powerful. Finally, 
in chapter 13 many of the previous ideas are combined in a sketch of how REASON 
will eventually be able to support program evolution. 
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Chapter 3: The Reasoning System 

Understanding programs requires a sophisticated reasoning capability. This chapter 
describes REASON'S basic deductive system. REASON has its antecedents in two 
separate works. The first of these is an earlier program implemented in LISP which 
was reported on in [Rich & Shrobe, 1976]. The current version of REASON is 
writlen in a variant of AMORD [DeKleer, et al 1977] a language for constructing 
prob em solvers. Both systems maintain a dependency network, but the AMORD 
system does so in a cleaner manner, utilizing the Truth Maintenance System 

[Dotyle, 1978]. I will begin by reviewing the basic concepts and constructs of the 
syste m. 

Section 3.1: Dependencies and Justifications 

REASON is implemented in a variant of the language AMORD. I will begin by 
reviewing the syntax and basic concepts of this language. 

Imagine a reasoning system which knew that numerical ordering is transitive. 
Suppose also it knew that X was less than Y and that Y was less than Z. 

Presumably, an "ordinary theorem prover" would then conclude that X was less than 
Z. However, the system could in principle deduce more than just this. It knows that 
X is less than Z because it is less than Y which is in turn less than Z and because the 
ordering is transitive. 

REASON like some other newer systems [Doyle, 1978], [London, 1977], [Stallman 
and Sussman, 1977] regards the justification for the new fact as an object of great 
importance to the theorem prover itself. The justification for the new fact tells us 
wh^t other facts the new fact depends on If we did not believe that X was less than 
Y or that Y was less than Z or than numerical ordering is transitive then we ought 

not 1 o believe that X is less than Z A justification states such a dependency between 

facts 

REASON'S goal is not only to prove properties of a program but to understand 
how these properties follow from known or assumed properties of sub-modules. Hence 
such dependencies are a crucial form of information in REASON. When an assertion 
is entered into REASON'S data base, it is always accompanied by a justification 
explaining why the new assertion is believed. To make this convenient, as each 
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assertion is entered into the system's database it is assigned a unique "fact-name" by 
which it may be referenced. For example: 


Assertion System-Supplied Fact-Name 

(< X Y) F-1 

(< Y Z) F-2 

The user may add the the fact deduced from the above by calling the ASSERT 
function: 


(Assert '(< X Z) '(Transitivity F-l F-2)) 

assert takes two arguments: the new assertion to be added to the data base and the 
justification for the assertion which is a list whose first element is a justification type 
and whose remaining elements are the fact-names upon which the new assertion 
depends. 

(Assert <fact> (<justification-type-name> ... <fact-name> ...)) 


One important justification type is premise which, as the name suggests, indicates 
that the fact is believed without further justificatioa A premise justification has no 
supporting facts. The three facts about ordering shown above could well have been 
entered into the system as follows: 


User Types System-Supplied Fact-Name 

(Assert '(< X Y) '(Premise)) F-l 

(Assert '(< Y Z) '(Premise)) F-2 

(Assert '(< X Z) '(Transitivity F-l F-2) F-3 

The rudimentary facility of any logic system is a mechanism for making deductions. 

REASON accomplishes this using rules which consist of two elements: a trigger-set and 
a body. The trigger-set is a list of patterns each of which has two parts: a fact-name- 
variable and an assertion-pattern. The body is a LISP expression which is evaluated in 
an environment in which the variables of the patterns are bound to the objects which 
they match. The following is a fairly typical REASON rule: 
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(rule ((:f (Rest :list-l :list-2)) trigger 

(:g (Member :1ist-2 :obj-l))) set 
(assert '(member :1ist-l :obj-l) '(List-Membership :f :g))) 
fact justification 

Vailiibles are indicated by a leading colon (:). 

Here the body is the assert statement The trigger set is the list 

(( :f (Rest :1 ist-1 :1 ist-2)) 

( :g (Member :1ist-2 :obj-l))) 

In tnese triggers, the leading single variable (:F or :g) is the fact-name variable, the 
remaning part of each trigger ( (rest :list-i :list- 2 ) or (member :list -2 :obj-i) ) is the 
assertion pattern. Rules are dealt with in 3 stages. 

(i) V r hen an assertion is added to the data base, all rules with a trigger whose 
assertion pattern matches the new assertion are triggered. 

(ii) Each of the remaining triggers are examined to see if their assertion pattern also 
matches an assertion in the data base. However, these matches must be consistent 
with the variable bindings created by the earlier matches. 

(iii) f all of the triggers have a matching assertion, then the rule is applicable and its 
bodj is executed in the binding environment created by the match. 

As each trigger is matched to an assertion, the fact-name variable of that trigger 
is bound to the fact-name of the matched assertion. This allows the body of the rule 
to i[< fer to its triggering facts. In particular, assert statements in the body of the rule 
may include a justification mentioning these facts. 

At each moment any assertion has one of two statuses in REASON, it is either 
in 01 out. A fact which is in is believed to be true. An assertion whose negation is 
in i£ believed to be false. If both an assertion and its negation are in then the data 
bas^ is contradictory and corrective action is required. If neither the assertion nor its 
neg$ :ion is in, then the truth-value of the fact is simply unknown. 
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assertion true 
assertion false 
contradiction 
truth value unknown 

Facts which are out may be brought in by asserting the fact with a valid 
justification. A fact which is in may be made out using the function retract to 
remove a valid justification. If no valid justification is left, the fact goes out. When 
a fact goes out a check is made to see which other facts are affected by the change 
of status of the first fact If the first facts going out invalidates the support of some 
other fact, then the same checks are made recursively, outing all facts which now lack 
well founded support Similarly, if a fact comes in because new support for it is 
discovered, then a check is made to see which other facts are affected Any facts 
whose support is made valid by a change in status of the first fact are brought in. 
Such //ring and outing of facts is managed by the Truth Maintenance System, which 
insures that only facts with well founded support are in Thus, a fact which has 
never been asserted, is by definition out. 

The meaning of justifications such as the transitivity justification shown above is 
| that whenever f-i and f -2 are in then f-3 should also be in If for some reason either 

f-i or f-2 became out , then f-3 would lack support and would also become out (unless 

it has other support). 

It is frequently necessary to assume that some fact holds even though no reason 
exists for believing the fact This is often done in hypothetical reasoning as when one 
proves that a implies b by assuming a and deriving b. Since the assumed fact a has no 

!i simple support (as for example « x z) above) a different type of justification is 

required. One assumes a fact by making it depend on the oumess of its negation; 
thus, if the negation of the assumed fact should ever be proved, the assumption will 
go out. This is done by the function ASSUME: 

(Assume '(Made-of The-Moon Green-Cheese) '(Bil1-said-so F-23)) 


assertion 

in 
out 
i n 
out 


negated assertion 

out 

in 

in 

out 
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which states that the system will believe that the moon is made of green cheese as 
long as it has no reason to believe that the moon is not made of green cheese and as 
long as it believes fact f-23 (which presumably is a statement of what Bill told the 
system), assume takes two arguments: a fact to assume, and a list whose first element 
is an assumption-type-name (used only for mnemonic value) and whose cor is a list of 
fact+jiames which indicates the reasons for making the assumptioa Whenever all the 
fact-names in this list are in and the negation of the assumption is out , the assumed 
fact is brought in. 

This requires the justification built by assume to have two parts: A list of 
assenions upon whose mness the fact depends and a list of assertions upon whose 
01/ mess the fact depends. When the above assume form is invoked it creates the 
asseri ion: 

(Not (Made-of The-Moon Green-Cheese)) F -1001 

and then justifies the asser : on 

F -1002 (Made-of the-moon green-cheese) 

by stiting that F-1002 depends on F-1001's outness and on f- 23 's mness. 

F -1002 (Made-of The-Moon Green-Cheese) (Bill-said-so (F- 23 )(F- 1001 )) 

The justification of F-1002 is not the same list as the second argument of the assume 
whicr created F-1002. The justification is built by assume using the information 
provided in its calling arguments. The first list in the justification is the list of facts 
whose mness supports F-1002 and the second list is the out list This support structure, 
which was originated in Doyle's TMS [Doyle, 1978], allows the system to believe that 
the noon is made of green cheese until some deduction provides valid support for 
F-1001 At that point, F-1001, the negation of F-1002, will become in (and thus not out). 
Since F-1002 depends on the outness of F-1001 it will lack support and thus become out 
itself. Similarly, if other facts had been deduced from F-1002 they would now lack 
support, since F-1002 would no longer be in The Truth Maintenance system 
propagates these changes of status until only assertions with well-founded support 
remai ned in 
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Notice that in the support structure for assumptions, adding a new assertion to 
the data base (e.g. the negation of an assumed assertion) can cause an assertion which 
is in (the assumed one) to become out. Thus, the number of things believed to be 
true can decrease as assertions are added. For this reason, such a support structure is 
referred to as non-monotonic When a contradiction is detected, the system finds 
those assertions which are supported by non-monotonic dependencies (Le. on the 
outness of others) and brings in one of the assertions upon whose outness they depend. 
Since the system maintains the dependencies between facts, it is easy for it to find 
only those assumptions which logically are related to the contradiction and to use 
these as the candidates for rejection. This avoids the thrashing which was found to 
occur in chronological backtracking systems such as Micro-Planner 

[Sussman, et aL 1971] and even in more flexible systems where dependencies were not 
explicitly maintained. This process is called dependency-directed backtracking 
[Stallman & Sussman, 1977]. 

Sometimes it is necessary to make an assertion depend on the //mess of some 
facts and the outness of a second set of facts. This can be done by calling assert 
with a justification argument whose first element is sl. Such a justification should 
have three other elements: A mnemonic name, a list of facts upon whose //mess the 
new fact depends, and a list of facts upon whose outness the new fact depends. For 
example: 


(Assert '(Hacker Howie) '(SL MIT-people-hack (F-l) (F- 2 ))) 

will create the new assertion F-3 justifying it so that it will be in whenever f-i is in 
and f-2 is out. Thus, we would have: 

Fact-Name Assertion Justification 

F -1 (Hacker Howie) (MIT-people-hack (F-l) (F- 2 )) 

A final type of justification arises in the proofs of implications. As mentioned 
above, typically one proves ( implies a b) by assuming a and deriving b. The 
justification of (implies a b), however, is not logically the justification of b. It is, 
instead, exactly those facts which were involved in deriving b from a which were do 
not themselves depend on a. For example, consider the following trivial proof: 
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Fact-Name Assertion Justification 

F-l (Implies A C) (Premise) 

F-2 (Implies C D) (Premise) 

F-3 A (Assumption) 

F-4 C (Modus-Ponens F-3 F-l) 

F-5 D (Modus-Ponens F-4 F-2) 

F-6 (Implies A 0) (Conditional-Proof F-l F-2) 

As I mentioned above, the logical support of f-6 is precisely f-i and f- 2 . To calculate 
this the system can trace back through the dependencies to find those facts which 
support f-5 , the consequent of the implication. These are f-4 , and f- 2 . f-4 is, in turn, 
supported by f-3 and f-i. Of these assertions, we eliminate the hypothesis f -3 plus 
tho$o assertions which depend on it These are f-3 and f-4 , leaving only f-i and f -2 
which are then the support of f-6 . The system is instructed to perform such an 
analysis by asserting a fact with a justification whose justification-type is Conditional - 
Proof- 

(Assert '(Implies A D) '(Conditional-Proof F-5 F-3)) 

assert performs a special analysis when given a second argument whose first 
element is the justification-type conditional-proof. The first fact-name in a 

Coriditional-Proof justification is the consequent of the implication, the second fact- 
nanli i is the hypothesis of the conditional proof argument assert creates a justification 
for he above assertion in which the support for the assertion is the set of facts (such 
as f 1 and F- 2 ) upon which the implication relies. Thus, if f-i were to go out, f-6 
would lack support and go out itself. 

To facilitate the construction of complex dependency structures the system 
includes a primitive for creating an assertion which has no justificatioa This 
primitive is called assertion and takes a single argument, the assertion to be created 
It returns the fact-name of the new assertion. For example, evaluating 

(Assertion '(Hacker Howie)) 
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will cause a new assertion to be built and assigned a fact-name, say F- 2001 . Since this 
new assertion has no valid justification (it has no justification) it is out. At some 
later time, some rule might decide to give this fact a justification; if this justification 
is valid, F-2001 will come in For example, if we had the following fact and rule: 

F -2002 (At-Mit Howie) 

(rule ((:f (At-Mit :person))) 

(Assert '(Hacker :person) '(MIT-is-ful 1 -of-hackers :f))) 

Then the system would assert 

F -2001 (Hacker Howie) (MIT-is-ful 1 -of-hackers F- 2002 ) 

Remember that F-2001 was originally created with no justification Suppose at that 
point another assertion F-2C04 was created and made to depend on the outness of 
F-2001, as follows 


(let ((a (assertion '(Hacker Howie)))) 

(Assert '(Is-Careful howie) '(SI Hackers-are-loose () (,«)))) 

[Note: the comma used above is an "unquote" which causes the variable a to be 
evaluated even though its inside a quoted form. Also let is a macro defined in the 
standard MacLisp. The first argument to let is a list of pairs of variables and forms; 
each form is evaluated in the enclosing environment and then each variable is bound 
to value of its corresponding form. The remaining arguments to let are forms to be 
evaluated in the new environment created by the bindings.] 

When F-2001 was first created, it was out ; therefore F-2004 was in. However, 
when the rule above is triggered by F-2002 it executes and brings F-2001 in Since F- 20 M 
depends on the outness of F-2001 it then goes out. Conversely, if the support for f -2002 
is ever remove, using retract for example, the F-2001 will go out and F-2004 will come 
in This allows REASON to use justifications in building its control structures. 

I will now turn to the issue of control within the reasoning system. 
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Chapter 4: Explicit Control and The Task Network 

The traditional weakness of automatic deduction systems is that they are prone 
to b ind searches. The room for exponential explosion is so large that even large 
amounts of a fixed factor overhead are justified if they can cut down the size of the 
search space. 

The approach I have followed here is to represent all control of the deductive 
process explicitly in a form which can be manipulated by the same mechanisms as 
tho$( which conduct the logical deductive process itself. Such an approach has been 
followed in [DeKleer, et aL 1977], [McDermott, 1977], This allows the deductive to 
be S df-conscious, able to explain what it is doing and why it is doing it Such a 
system can reason about whether it ought to continue to pursue a particular task, or 
rathe r abandon it as hopeless or of too little importance to command further resources 
and attention. A system which is explicit in its control discipline can exhibit 
flexibility which is precluded in more traditional systems which encode their control in 
the state of procedures which can not be examined. 

This suggests a system which at the very least knows what task it is attending to 
and where that task fits into its larger goals. REASON organizes its operation around 
a data-structure called the task-network [McDermott, 1977] which makes this 
information explicit. The task network is represented by assertions in the data-base 
used to record facts about the program being analyzed. However, the control 
assertions in the data-base have a justification structure which outs them once their 
usetfi lness has passed. 

A simple example of the use of control assertions in consequent reasoning will 
perhaps clarify the discipline used in REASON. In consequent reasoning the system 
attempts to chain backward from its current goal to sub-goals which interact to imply 
the nain goal and which are (hopefully) closer to facts which are already known 
expli utly. 

For any particular goal there might be several different methods for deriving the 
desirid fact A particular fact about a list might be derived by backward chaining 
thob^h some implication, or it might be deduced by structural induction. In general 
one would tend to prefer the simpler method, however, there are cases in which the 
opposite would be the better strategy. 
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This has led to the following protocol. A goal is entered into the system by calling 
the primitive goal-assert. This takes three arguments: The first of these is the 
assertion to be proven. The second argument is used to indicate what higher level 
task gave rise to this goal, (this is usually some sub-task of the symbolic evaluator, 
but for simplicity of presentation I will call this task top-level). The third argument is 
a justification (just as would be given to assert). A goal created by goal-assert should 
remain in as long as it is neither refuted nor satisfied and as long as its justification is 
valid. To achieve this, goal-assert creates two assertions one stating that the goal is 
satisfied, the other stating that it is refuted. REASON builds an assertion stating 
the existence of the new goal. This assertion is given a justification which is identical 
to the justification passed in as an argument except that the new justification includes 
a dependency on the outness of the assertions which state that the goal is satisfied or 
refuted. The goal assertion will remain in until the goal is either satisfied or refuted 
at which time it will go out. 

The assertion of a goal is an implicit request for the proposal of methods which 
might be capable of proving the assertion. If the particular goal is of a type for 
which a method is known, then the method is proposed. This proposal is given a 
justification which points to the goal assertion. A special procedure called the acceptor 
is responsible for choosing the order in which the various methods for a goal should 
be tried. The primitive propose-method is used to propose a method; it takes three 
arguments: an assertion stating the method to propose, a justification for this assertion, 
and a body to execute if the method is ever accepted. 

If the desired goal is ever proven, then an assertion is made saying that the goal 
is satisfied. If the negation of the goal is ever discovered, an assertion is added 
stating that the goal has been refuted. Either of these events causes the original goal 
assertion refuted to go out , taking with it all of the dependent control assertions. 
However, normal fact assertions will never depend on these control assertions; even 
when the control assertion are made to go out , the facts deduced stay in if they are 
logically valid. 

What makes this protocol possible is a mechanism (developed in [Doyle, 1977J 
which establishes well-defined points at which the system may chose which method to 
pursue, REASON is a queue based system whose main loop consists of finding pairs 
of rules and matching facts. At each iteration one such pair is removed from the 
queue and processed, potentially creating new facts and rules and thus new pairs of 
matching facts and rules. However, at certain times there will be no such pairs of 
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rules and facts to process. The method proposing and accepting protocol guarantees 
that new triggering pairs will not be created in an explosive manner, but will rather 
prod jce proposals for actions which must be accepted before new actions can occur. 
Ever though the tree of possible methods and sub-goals might be exponentially 
explosive, the system has the option of choosing which branches to leave unexplored. 
As 1 )ng as the system chooses to pursue only a few branches at at time, the queue 
will r un out of pairs frequently. 

This is the occasion for the special acceptor procedure to be invoked. The 
acceptor is a procedure run each time the queue runs out Its purpose is to examine 
the network of goals and methods, hopefully finding at least one which it deems 
worti pursuing. The acceptor is allowed to add control assertions to the data base 
and these are allowed to trigger rules which will, in turn, add assertions to the data 
base. However until it accepts a method, no further work on the goals at hand will 
be performed. This organization, which is still being developed, allows the machinery 
of ti e reasoning system to be used in deciding which goals should be pursued. Once 
such a decision is made, a method is accepted triggering the rules which actually do 
the ^vork. 

A simple example will illustrate the technique. Suppose we want to prove P and 
we lave (implies q p), (implies r q) and R. We would start off by stating that we have 
the roal P: 


F-l (Implies 0 P) (Premise) 

F -2 (Implies R 0 ) (Premise) 

F -3 R (Premise) 

(GOAL-ASSERT 'P '(top-level) '(Premise)) 

Since a goal statement has been entered, the system makes the assumption that 
the {oal has as yet been neither satisfied nor refuted. Also it creates a goal statement 
for t tie newly created goal and justifies this statement as explained above. 


! 
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F-6 

(Satisfied F-9) 

(); no justification, therefore OUt 

F-8 

(Refuted F-9) 

(); no justification, therefore OUt 

F-9 

(Goal P (top-level)) 

(Sub-goal() (F-6 F-8)) F-6 & F-8 OUt 

implies F-9 is itl. 

Notice 

that the goal assertion 

f-9 includes both the fact to be proved and a list of the 


super-tasks which have led to the existence of this goaL Two rules are also created 
by goal-assert; one watches for the goal becoming true, the other watches for 
refutations. Both these rules depend on the fact f-9. 


R-l (Rule ((:f P)) (Sat-Rule F-9) 

(Assert '(Satisfied F-9) 

'(Satisfaction :f))) 

R-2 (Rule ((:f (Not P))) (Ref-Rule F-9) 

(Assert '(Refuted F-9) 

'(Refutation :f))) 

The assertion of the goal statement is an implicit request for the proposal of methods 
which might achieve the goaL The various method proposers now come into play. 
One obvious method is backward chaining, finding an implication whose consequence is 
the desired goal, and then posing the antecedent of the implication as a sub-goaL 
The following rule proposes the backward chaining method and then conducts the 
proof if the method is accepted. 

R-10 (Rule ((:fl (Goal consequent :stack)) 

(:f2 (Implies antecedent consequent))) 

(Propose-Method 

'(Method :fl (Backward-Chain :f2)) '(B-C :fl :f2) 

(goal-assert antecedent '(consequent . :stack) '(bc-sub-goal :f)) 

(Rule ((:g (Implies antecedent consequent)) 

(:h antecedent)) 

(Assert consequent (Modus-ponens :g :h))))) 

Notice the use of the primitive Propose-Method. This is actually a macro which 
expands as follows; 
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(Prop ise-Method Meth Just body) => (Let ((:a (Assert meth Oust))) 

(Rule ((:b (Accepted :a))) 
body)) 

The method proposer above leads to the following results: 

F-11 (Method F-9 (Backward-Chain F-l)) (BC-Meth F-19 F-l) 

The queue now runs out since there are no other actions possible. At this point the 
acceptor is invoked. Seeing only one method available, the acceptor makes the obvious 
choice accepting the method proposed in f-ii. 

F-12 (Accepted F-11) (Acceptor F-11) 

The acceptance of the method proposed in f-ii allows the method proposer to 
cont nue its work. This creates the following rule which represents the inference rule 
of to odus-Ponens: 

R-ll (Rule (( :g ( Implies 0 P)) ("Rule" F-12 R- 10 ) 

( :h 0)) 

(Assert P (Modus-ponens :g :h))) 

Noti:e that when the system created the rule r-ii, it automatically generated a 
justi ication for it New rules are created by the execution of a rule expression which 
is typically nested within another rule; when this outer rule is triggered by some fact, 
the new rule is created with a justification indicating dependence on the outer rule 
and the triggering fact 

The body of the method proposer also creates the new sub-goal o triggering a 
serie s of assertions similar to those triggered by the original goal p. We get the 
folio ving: 


For 
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F -15 

(Satisfied F-18) 

0 


F -17 

(Refuted F-18) 

0 


F -18 

(Goal 0 (P top-level)) 

(Sub-Goal 

F-12 (F-15 F-17 )) 

R-3 

(rule ((:f 0 )) 

(Assert (Satisfied F-18) 

(Satisfaction :f))) 

(Sat-goal 

F-18) 

R-4 

(rule ((:f (not 0))) 

(Assert (Refuted F-18) 

(Refutation :f))) 

(Ref-Goal 

F-18) 

F-20 

(Method F-18 (Backward-Chain F-2)) 

(BC-Meth 

F-18 F-2) 


The acceptor is now invoked and Method f -20 is accepted 


F-21 (Accepted F-20) 


(Acceptor F-20). 


which in turn triggers the rule for backward chaining, resulting in: 


F -22 

(Satisfied F-24) 

0 


F -23 

(Refuted F-24) 

0 


F - 24 

(goal R (0 P top-level)) 

(bc-sub-goal 

(F-21)(F-22 F-23)) 

R-5 

(Rule ((:g (Implies R Q)) 

("Rule" F-21 

R-0) 


( :h R)) 

(Assert 0 (Modus-ponens :g :h))) 


At this point the necessary facts are available allowing rule r -5 to run on the fact f -3. 
Thus, we obtain: 


F-25 Q (Modus-Ponens F-3 F-2) 

However, 0 now triggers the rule r -3 which is watching for an assertion satisfying the 
goal f - is (goal q (p top-level)). This causes a justification to be added to the satisfied 
assertion, f -15, which was created when the goal f-is was created: 
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F-15 (Satisfied F-18) (Satisfaction F-23) 

However, the goal assertion f - is depends on the outness of f - is and the method and 
show assertions F -20 and f -2 1 depend on f-is. A quick inspection of the justifications 
will show that the following support structure exists at this time: 


F - IS ■=>> F-18 -> F-20 -> F-21 -> R-5 



whers a double headed arrow indicates non-monotonic support Thus, when F -15 
comes in, all of the other assertions go out. Notice, however, that all of these are 
contiol assertions. The fact assertion f -25 q depends only on f-3 and F- 2 ; it stays in. 
Furthermore, F -25 triggers the rule r -2 which represents the modus-ponens deduction 
for <3 and (implies op). We obtain: 

F-26 P (Modus-Ponens F-23 F-l) 

As before, this triggers a goal-satisfied rule, this time R-l for the goal F-b 

i 

F-6 (Satisfied F-9) (Satisfaction F-24) 

whici causes the goal assertion f-9 to go out. A similar chain of dependencies to that 
abovs causes assertions f-ii, F- 12 , and rules r-i, r -2 to go out as welL This leaves us 
with only the following useful assertions. 


For 
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F -1 

(Imp!ies 0 P) 

(Premise) 

F -2 

(Imp!ies R 0) 

(Premise) 

F - 3 

R 

(Premise) 

F-4 

(Subgoal P (top-level)) 

(Premise) 

F -6 

(Satisfied F-9) 

(Satisfaction F-24) 

F -15 

(Satisfied F-18) 

(Satisfaction F-23) 

F - 25 

0 

(Modus-Ponens F-3 F-2) 

F -26 

P 

(Modus-Ponens F-23 F-l) 


Of course, this entire deduction might have been achieved more easily by a 
simple forward chaining rule for modus ponens. However, I have gone through this 
detail to illustrate the steps of the protocoL In general, blind forward chaining is a 
bad strategy since it allows uncontrolled deductions to lead into endless loops. 
Suppose that we added the following facts to the data-base: 


(Implies (Number :x) (number (plus 1 :x))) 
(Number 1) 


Then the modus ponens rule would trigger infinitely often, filling the data-base with 
assertions of the form: 


(number I) 

(number (plus 1 1)) 

(number (plus 1 (plus 1 1))) 


Obviously, such infinite counting chains cannot be allowed to occur. On the 
other hand, it is desirable to allow some deductions to proceed in a forward manner. 
I have so far found it convenient to have both an antecedent and a consequent modus 
ponens rule; however, one must, therefore, avoid writing implications such as the one 
above. In the particular environment in which REASON operates one rarely wants to 
state implications like the one above anyhow. As we will see later, most of 
REASON'S knowledge is expressed in the form of descriptions of data-structures using 
a specially designed specification language. This allows the knowledge acquisition 
portion of the system to build rules which correspond to these specifications and which 
do not engage in uncontrollable forward chaining. 
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It should be pointed out that one of the distinct advantages of the regimen of 

expii :it control is that it is quite simple for the system to determine that it is 

enga *ing in infinite loops. If, for example, the same pattern appears as a subgoal of 

itself, then the system can decide not to pursue that subgoal by marking it as a loop 
and never accepting it Similarly it can set itself limits on how deep into a case 
analysis it will go before deciding that it’s on a losing course. Indeed, although our 
work has not yet progressed this far, the reasoning system can, in principle, reason 
about what that limit ought to be given the particular circumstances it which it 

currently finds itself. This begins to suggest the idea of the reasoning system having a 
"stats of mind". 


i 

i 

i 

|| 
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Section 4.1: Hypotheticals 

The actual protocol is, in fact, more complicated than what I have illustrated so 
far. The complication is caused by the use of hypotheticals, particularly in conditional 
proofs. As a paradigmatic case consider the following problem (I will omit the 
refutation assertions in this example for the sake of brevity): 


Given : (Or A B) 

(Imp!ies A C) 

(Implies B C) 

(Implies C D) 

To Show: 0 

REASON might attack this problem in a manner similar to that employed above, 
backward chaining from the goal d to both a and c. At this point it recognizes that 
case-splitting the disjunction (or a b) is an appropriate method. This creates a set of 
conjunctive sub-goals, in this case, (implies a d) and (implies b d). Each of these is 
proven by the standard conditional proof method, assuming the antecedent and 
attempting to prove the consequent The following is an excerpt of the assertions that 
result: 
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F -30 
F -31 
F -32 
F - 33 

F - 54 
F -55 
R-l 


F -65 
F -67 

F-99 | 
F-100 | 
R-2 | 


F -105 
F -110 

F -112 
F -113 

F -122 

F -125 
F -126 
R-3 


F-127 


(or a b) 

(implies a c ) 

(imp 1ies b c ) 

(imp!ies c d) 

(satisfied F- 5 5 ) 

(goal d (top-level)) 

(Rule ((:f d)) 

(Assert '(satisfied F-55) 
’(Goal-Sat :f))) 

(method F-55 (splitting F-30)) 
(accepted F-65) 

{ satisfied F-100 ) 

(goal (implies a d) (d (top-level))) 
(Rule ((:f (implies a d)) 

(Assert '(satisfied F-100) 
’(Goal-Sat :f))) 

(method F-100 (standard-implication)) 
(accepted F-105) 

a 

(Not a) 
c 

(satisfied F-126) 

(goal d ((implies a d) d (top-level))) 
(Rule (( :f d)) 

(Assert '(satisfied F-126) 
'(Goal-Sat :f))) 


(premise) 

(premise) 

(premise) 

(premise) 

(); No support, therefore I'm OUt 
(subgoal (F-47) (F-54) ) 

(goal-sat F-55) 


(method F-55) 

(acceptor F-65) 

, No support, therefore I'm Out 
(subgoal (F-74) (F-99)) 

(goal-sat F-100) 


(si-method F-100) 

(acceptor F-105) 

(imp-assump (F-110) (F-113)) 

0 

(mp F-31 F-112) 

(); No support, therefore, I'm OUt 
(subgoal (F-110)(F-125)) 

(goal-sat F-126) 


d 


(mp F-33 F-122) 


F-126. 

at w 
satisfi 
does 
goal 


Notice the rules r-i, r -2 and r-3 which correspond to the goals F- 55 , F -100 and 
Two of these (r-i and R- 3 ) are waiting for the same fact (F -127 d ) to come in 

|iich time each will rule will assert that its goal (F -55 and F -126 respectively) is 

ed. This, however, is an obvious mistake If F -127 o comes in at this stage, this 

not imply that o is true, only that 0 follows from the assumption a. Thus, the 

-55 should not be satisfied by this occurrence of d. 
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The classic solution to this problem in AI systems such as PLANNER 
[Hewitt, 1972] CONNIVER [McDermott 1973], and QA4 [Rulifson, et aL, 1972] is to 
use a context mechanism to represent the "echelon" in which the implication will be 
derived. Typically, a new context is created in which the assumption a as well as the 
new goal o (or its analogue) are asserted. When the fact o comes in, the satisfied 
assertion is added to the new context which is then discarded; only (implies a o) is 
returned to the old context The problem with this approach is that it is altogether 
possible that the fact o derived in this new context might not depend on the 
assumption a, in which case the system ought to assert that the main goal d is satisfied 
and terminate the process; the context system is incapable of doing this since the 
contexts do not represent logical dependency but only the chronology of the problem 
solver's behavior. Lacking any representation of logical dependency, a context system 
becomes overly rigid. 

REASON instead uses the dependencies maintained by the truth maintenance 
system as well as the explicit control assertions to guide itself to appropriate 
conclusions. Goal assertions contain within them a goal stack, indicating the chain of 
subgoals which led to the current goal. Although each such assertion includes a 
(linear) stack, the set of all such assertions is a (potentially non-linear) network, since 
the same goal may be reached by several different paths. The stack is included in 
goal assertions for two reasons: First it allows two nested occurrences of the same goal 
(such as D above) to be distinguished by their goal stacks. Since the two goals are 
represented by different assertions we may easily say that only one is satisfied while 
leaving the other to remain as an active goal 

The second reason for this representation is connected with the use of 
hypotheticals such as the assumption A made in trying to prove (Implies A D). The 
goal assertions actually used in REASON are an extension of those I have shown so 
far, including not only the goal stack, but also a set of assumptions made as part of 
the deduction process. These assumptions are referred to as the context , although this 
context should be distinguished from that of CONNIVER or QA4, in that the 
assumption set is an unordered set, while CONNIVER and QA4's contexts are strictly 
nested. Every time a new assumption is made for the sake of hypothetical reasoning 
(as in proofs of implications or in indirect proofs) the newly assumed fact is added to 
the context part of the goal assertion associated with that assumption. To facilitate 
this, the primitive goal-assert takes one more argument than shown above, namely the 
assumption context Thus, the same set of assertions as shown above will now be 
represented as follows: 
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F -30 
F -31 
F -32 
F -33 

F - 54 
F -55 
R-1 


F -65 
F -67 

F -99 
F -100 


R-2 


F-105 
F -110 

F-112 

F-113 

F -122 

F-125 
F -126 


R-3 


F -127 


keyw 
it is 


(or a b) 

(implies a c) 

(implies b c ) 

(implies c d ) 

(satisfied F-55) 

(goal d for (top-level) in ()) 

(Rule ((:f d)) 

(Assert '(satisfied F-55) 
'(Goal-Sat :f))) 

(method F-55 (splitting F-30)) 
(accepted F-65) 

(satisfied F -100 ) 

(goal (implies a d) 
for (d (top-level)) in ()) 

(Rule ((:f (implies a d)) 

(Assert '(satisfied F-100) 
'(Goal-Sat :f))) 

(method F-100 (standard-implication)) 
(accepted F-105) 

a 

(Not a) 


(satisfied F-126) 

(goal d 

for ((implies a d) d (top-level)) 
in (a)) 

(Rule ((:f d)) 

(Assert '(satisfied F-126) 
'(Goal-Sat :f))) 

d 


(premise) 

(premise) 

(premise) 

(premise) 

(); No support, therefore I'm OUt 
(subgoal (F-47) (F-54)) 

(goal-sat F-55) 


(method F-55) 

(acceptor F-65) 

; No support, therefore I'm OUt 
(subgoal (F-74) (F-99)) 

(goal-sat F-100) 


(si-method F-100) 

(acceptor F-105) 

(imp-assump (F-110) (F-113)) 

(); No support, therefore I'm OUt 

(mp F-31 F-112) 

(); No support, therefore, I'm OUt 
(subgoal (F-110)(F-125)) 

(goal-sat F-126) 


(mp F-33 F-122) 


n goal assertions the keyword "for" indicates the subgoal stack while the 
>rd "in" indicates the assumption context When the fact F -127 0 comes in now, 
»ossible to determine which goal it actually satisfies. The rule is as follows: 
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Given an assertion P which triggers the pattern of a rule which is watching for the 
satisfaction of some goal 

1. Request the Truth Maintenance System to prepare a list of all assumptions which 
support the satisfying fact P. 

2. Fetch all goal statements whose goal matches the satisfying fact P. 

3. For each goal assertion test whether the assumptions found in step 1 are a subset 
of the assumptions listed in the goal assertion's context list 

4. Discard those goal assertions which fail the test in 3. 

5. For each of the remaining goal assertions in 4 assert that the fact P satisfies the 
goal assertion. 

This procedure results in the following assertion when applied to the situation 
; described above: 


F-120 (satisfied F-126) (goal-found f-127 f-112) 

However, REASON does not assert that the original goal assertion F -55 0 is satisfied 
since it has an empty assumption context while the assertion F -127 depends on the 
assumption F -112 a. 

This process is driven by the rules which watch for the presence of goal- 
satisfying facts, yet these rules in the current system are required to be stated in a 
more procedural manner than desired The algorithm we have just stated is one 
which determines whether a certain pattern of dependencies obtains and acts only in 
that case. Given the philosophy of explicit control in a rule based system, it would be 
preferable to include such dependency patterns in the triggering list of a rule, simply 
allowing it to run whenever the appropriate combination of support and facts obtains. 
Unfortunately, the current mechanisms are considerably too weak to implement these 
desiderata and we are forced to employ more awkward mechanisms. What one would 
like is to be able to write something like the following: 
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(Rule ((:fl (goal :g for :stack in :context)) 

(:f2 :g) 

(? (subset (assumption-support :ti) :context))) 

(assert '(satisfied :fl) '(goal-found :f2))) 

wheje the intention is to treat the third clause as if it were a fact, triggering the rule 
whenever the condition expressed in this clause is true. This, however, puts a burden 
on the truth maintenance system to not only be aware of changes in the in and out 
statuses of facts, but also to be aware of more complex conditions, signalling these to 
the jeasoning system as welL 

| This poses an interesting research direction for future work which I have not yet 
pursjied. Is it possible to develop a lexicon of such useful justification patterns and to 
extend the truth maintenance system to support the facility just outlined? 

The partial solution I have adopted is to have a special kind of rule called a 
trigger rule which runs each time all its pattern's come in The body of this rule is 
then free to perform further checks to determine if it wants to proceed; in particular, 
it ci n investigate the support patterns of various assertions. If these patterns of 
support are appropriate, the rule can then add assertions to the data-base. If not, it 
can simply exit; however, if the triggering patterns of the rule all become in at some 
later time, then the trigger rule will execute again, allowing the support pattern to be 
checked once more. 

This treatment of trigger rules is different from normal rules. When a normal 
rule matches a set of facts, it is run on this set of facts exactly once: the first time 
that all the facts are in Normal rules are concerned with truth; they implement 
deductions which are thereafter maintained by the truth maintenance system. When a 
rule runs, its job is to create new facts and to provide the TMS with a justification 
for e ach of these. As we've seen, a justification consists of two sets of facts: the in 
antec edents and the out antecedents. These later are used only in assumptions. The 
TMS views justifications as permanent implications: the mness of the in antecedents 
together with the ow/ness of the out antecedents implies the mness of the consequent 
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Thus, a rule concerned with truth need only run once on any set of triggering 
facts since the pattern of support it creates is eternal and can be handled by TMS 
without further executions of the rule. Trigger rules are, in contrast, concerned with 
utility and control, concepts of much greater plasticity; they, therefore, require the 
additional flexibility of executing any time their trigger facts change status to in 

Once the trigger rule has executed, REASON concludes that the implication 
(implies ad) is proven. This is justified by a conditional proof justification; the 
computed support is independent of F-112 and includes only F-31 (implies a c) and F-33 

( Impl ies CD). 

REASON moves on to the second half of the case-split This proceeds in exactly 
the same manner as above. In this half, f-130 e is assumed which leads to f-i 22 c by 
Modus Ponens. The TMS already has a justification which says that if f-122 is in, 
then f- i 27 should be in as well; therefore, F-127 is brought in and the trigger rules run 
again. The trigger rule for the first side of the split is out since it depended on the 
goal F-55 which, since it is satisfied, is out; the trigger rule for the second side of the 
split and for the main goal F-55 are in. This time they conclude that the new sub¬ 
goal o is satisfied; therefore, (implies b 0) is proved. Its conditional proof justification 
computes that the support includes only F-32 (implies b c) and F-33 (implies c d). The 

| ma,n g° a l F 55 > however, still cannot be satisfied, since F-127 o still depends on F-130 b, 

an assumption not in F-55's context set 

However, the case analysis is now completed; F-127 d has been derived from both 
| sides of the split It is asserted with its justification pointing at the disjunction used 
for the case analysis and the implications proven on each side of the split The 
trigger rule associated with F-55, the main goal, is still in and is triggered once again. 

This time it succeeds since the current support of F-127 includes no assumptions at all, 

but only the facts F-30, F-31, F-32, F-33. 
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Section 4.2 1 The Rules Of Inference 

In the following pages, I will present the rules of inference currently used in the 
expe|imental system. These should not be regarded as finished products, but as 
experiments along the way. Similar rules may be found in [Doyle, 1977). These rules 
are essentially the normal rules of standard logic embedded within the discipline of 
explbit representation of control information. It should be noted that these rules have 
the property that no non-control assertion will ever depend on a control assertion; 
thus, the logical validity of normal assertions is independent of the control regime. 

The reader should also note that I do not show here those rules which are 
responsible for selecting among competing methods. These are still under 
deve opment 

Contradiction Signalling 
signal a contradiction to the TMS if both a fact and its negation are ia 


(Rule 


(Rule 


For 


((:f :p) 

( : f (not :p))) 

(assert '(and :p (not :p)) '(contradiction :f :g))) 


Double Negation Simplification (Not Elimination) 


((:f (Not (not :p)))) 

(assert :p '(double-negation-elim :f))) 
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Antecedent Use of If-Then-Else (If-then-else elimination) 

If the antecedent of an if-then-else is in assert the fact for the then branch. If the 
negation of the antecedent is in, assert the fact for the else branch. 

(rule ((:f (if :cond then :true else :false))) 

(rule ((:g :cond)) 

(assert :true ' (if-the-else-true :f :g))) 

(rule (( :g (not :cond))) 

(assert :false ' (if-then-else-false :f :g)))) 


Modus Ponens (Implication Elimination) 


(rule ((:f (implies :a :b)) 

( : g : a)) 

(assert :b '(mp :f :g)))) 


Quantifiers 

The quantifiers used in REASON are slightly different than those of normal logic 
systems. The universal quantifier is a restricted quantifier with the force of an 
implication, for example: 

(For-all (:x) (Member the-table :x) 

(not (Key-part :x key- 1 ))) 

which states that no member of the table has key equal to key-1. 

The existential quantifier is always coupled with a such-that clause which has the 
force of a conjunction, e.g. 

(There-is (:x) (Member the-table :x) 
such-that (key-part :x key-1)) 

Each quantified statement includes a list of variables bound by the quantifier; the first 

clause of either type of quantified statement must mention all variables in this list; the 
second clause may not have any free variables. 


i 
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Antecedent Use of Universal Quantification (Universal Elimination). 


If ah object exists which matches the antecedent of the 
consequent clause (with the bindings substituted in). 


for-all, then assert the 


(rule 


((:f (for-all :vars :p :q)) 

(:g :p)) 

(assert :q '(for-all :f :g)))) 


i 

For Example, if 


(For-U 1 

I 

I 


( : x) (member 1 ist-1 :x) 

(there-is (:y) (sublist list-1 :y) 
such-that (first :y :x))) 


is matched against 


(Member list -1 Object- 22 ) 

we Jould then eliminate from the universal, obtaining: 


(Ther^ 


-is (:y) 
-that 


r h 


(sublist list-1 :y) 
(first :y Object- 22 )) 
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Universal Introduction 

(rule (( :f (goal (for-all :vars :p :q) for :goal in :context))) 

(propose-method 

'(Method :f (typical-member)) '(UITM :f) 

(let ((subst (ui-buiId-subs :vars))) 

(let ((:newp (instance :p subst)) 

(:newq (instance :q subst))) 

(goal-assert '(implies :newp :newq) 

'((for-all :vars :p :q) . :goal) 

:context 

'(for-al1-sub-goal :f)))) 

(rule ((:g (implies :newp :newq))) 

(assert '(for-all :vars :p :q) '(ui :o))))) 

Where ui- build-subs binds each variable in :vars to a newly created anonymous object 
(see next section). An anonymous object is one whose identity is unknown; it is a 
priori impossible to tell whether an anonymous object is identical to another object 
ui-build-subs also marks each anonymous object it creates as a ui-object (using the 
object's property list); this mark is used by the existential introduction and elimination 
rules to prevent certain logical bugs explained below. 
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j| 


Expansion of Existential Quantification on Demand (Existential Elimination) 

The j reasoning system occasionally will want to expand an existential, replacing the 
variable of the quantified statement by an anonymous object. However, if the 
existential contains ui -objects (objects created for Universal Introduction) then the 
anonymous objects created are marked to show their dependency on the ui- objects. 


(rulej((:f (there-exists :var$ :fact such-that :pred))) 

(rule ((:g (expand :f))) 

(let ((:subst (ee-bui1d-subs :vars :pred :fact))) 

(let ((:new-fact (instance :fact :subst)) 

(:new-pred (instance :pred :subst))) 

(assert :new-fact '(there-is :f)) 

(assert :new-pred '(there-is :f)))))) 

wherji ee-build-subs creates a substitution which binds each of the variables in :vars to 
a nejvly Created anonymous object instance is a function which substitutes these 
bindings into its second argument Expand assertions such as referred to in the above 
rule are asserted occasionally during symbolic program evaluation. 

As mentioned ee-builo-subs marks the newly created anonymous objects for their 
dependence on ui- objects. For example, if object-i is a ui-object and we have the 
following: 

(Therd-is ( :y) (Member object -1 :y) such-that (key :y key- 1 )) 

and Existential elimination creates member-i, an anonymous object, and substitutes this 
for :v, then ee-build-subs will mark member-i to show its dependence on object-i. We 
will cjibtain the assertions: 

(Membejr object-1 member-1) 

(Key njember-i key- 1 ) 

and fhe property list of member- 1 will be marked so that the ui-dependency property of 

MEMBE^-l is the list (OBJECT-1). 
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Existential Introduction 

j 

(rule (( :f (goal (there-is :vars :p such-that :q) for :goal in :context))) 

(Propose-Method 

'(Method :f (Standard-EI)) '(EISM :f) 

[ (goal-assert :p 

'((there-is :vars :p such-that :q) . :goa1) 

:context 

'(there-is-sub-goal-1 :f)) 

(rule ((:g :p)) 

(cond ((ui-object-free :p :vars) 

(goal-assert :q 

'(:p . :goal) 

:context 

'{there-is-sub-goal-2 :f :g)) 

(rule ((:h :q)) 

(Cond ((ui-object-free :q :vars) 

(assert '(there-is :vars :p such-that :q) 

'(exist-intro :h :g)))))))))) 

I The function ui-object-free checks to see whether the matching has resulted in a 
variable of either : p or : q becoming bound to an expression containing an anonymous 
| object which is marked with a UI-DEPENDENCY property. If so, this expression 
cannot be used to introduce an existential. This prevents the classic mistake of using: 

(for-all ( :x) (object :x) (there-is (:y) (object :y) such-that (P :x :y))) 

to conclude-* 

(There-is ( :y) (object :y) such-that (for-all (:x) (object :x) (P :x :y))) 

(where object is a predicate true of everything, and is used merely to fill the first 
position of my restricted quantifier notation). 

There are some delicate issues of control involved in simultaneous sub-goals which 
share variables. These come up in proving existential quantifiers like the ones used 

here. [Doyle, 1977] discusses these problems and presents a more advanced solution 
than I have used here. 
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! Expansion of And (And Elimination) 

( rule (:f (and :p :q)) 

(assert :p '(and-elim :f)) 

(assert :q '(and-elim :f))) 


Disjunctive Elimination (Or Elimination) 

This! is done in two parts. When a disjunct is asserted, it is put into an expanded 
forth so that rules can easily determine whether a particular fact is a clause of the 
disjunction. Then, if a clause in a disjunction is ever negated, a new disjunction can 
be a iserted, including all the other clauses of the old disjunction. 

Set Up Expanded version of Disjunct 

(rulej (( :f (or . :x))) 

(do ((dis :x (cdr dis))) 

((null dis)) 

(let ((:dis (disjunct-of :f .(car dis)))) 

(assert :dis '(spread-disjuncts :f))))) 

The double quote (") is a macro which produces a list The items inside the list are 
not evaluated unless preceded by a comma (,). Variables (e.g. :f) are always evaluated 
let contains two parts: a set of binding expressions and a body. Each binding 
expression contains a variable and an expression. The variable is bound to the value 
of the expression. The body is executed in the environment created by these bindings. 
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The exclamation point character (!) is a macro which when applied to a fact name 
produces a fact statement Le !:d = (Or ... ) in the above, safe-delete is a variant of 
the built-in LISP function delete which does not side-effect its argument 

Simplify singleton or 

If the above leads to a disjunction with only one clause, that clause may be asserted 

(rule ((:f (or :p))) 

(assert :p 1 (or-simplification :f))) 


The Basic conjunctive goal mechanism: 

This is essentially a sub-routine called by other strategies. The routine will try 
each of the sub-goals in turn A later sub-goal will not be tried until the prior sub¬ 
goal is satisfied. A refutation will stop the iteration, asserting that the calling goal is 
! refuted. Thus, this should be called only when the conjunction of the sub-goals is 
equivalent to the calling goal. 

The call is made by asserting: 

(conjunctive-goals :first :rest :dep :stack :context) 

where the arguments have the following meaning; 

I 1. first; the first sub-goal to attempt 

2. rest; the remaining sub-goals to attempt after the first is satisfied. 

3. dep: previously accumulated assertions upon which the final goal will depend. Each 
time a sub-goal is satisfied, the satisfying fact is added to this argument 

4. stack: the goal stack with which the invocation was made. The first item on this 
j stack is the immediately dominating goal. If all the sub-goals are satisfied, we can 

conclude that the first element on the stack is satisfied. 

5. context; the assumption context in which this is invoked 
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Conjunctive Sub-Goal Mechanism 

(rule ((:f (conjunctive-goals :first :rest :dep 

1 (:top . :stack) :context))) 

I (goal -assert .first * ( :top . :stack) rcontext '(conjunctive-goals :f)) 

| (rule (( :g (not :first))) 

(Assert '(Not :top) '(Conj-goal-refutation :g))) 

(rule (( :g : first)) 

(cond 
( : rest 
(assert 

'(conjunctive-goals (car :rest) (cdr :rest) (:g . :dep) 

(:top . .stack) :context) 

'(conjunctive-goal-control :f :h))) 

I U 

(assert :top '(conjunctive-goals :g . :dep)))))) 

Proof by cases 


Split, a disjunction, creating a case analysis. In each case attempt to show that the 
curr* nt clause of the disjunction implies the desired goal. This is done by creating a 
sub-i ;oal which is the conjunction of these implications. Conjunction Introduction will 
invol e the conjunctive goal mechanism to conduct the proof. 

(rule ((:g (goal :p for :goal in :context)) 

( :h (or . :q))) 

| (Propose-Method '(Method :g (splitting :h)) '(Split-Meth :g :h) 

[ (let (( :qf '(and . .(mapcar '(lambda (x) '(implies ,x ,:p)) :q))) 

(goal-assert :qf '(:p . :goal) :context 

'(use-conj-goals-for-case-split :g :h)))))) 


For Complex Program Understanding 



82 Explicit Control and The Task Network 


Implication Introduction 

(rule (( :f (goal (implies :a :b) for :goal in :context))) 

(Propose-Method '(Method :f (Standard-Imp-Intro)) ' (S11 :f) 
(goal-assert :b 

'((implies :a :b) . :goal) 

'(:a . :context) 

'(implies-subgoal :f)) 

(assume :a '(standard-implies-rules-assumptlon :f)) 

( rule (( :h :a) 

( :g :b)) 

(assert '(implies :a :b) '(cp :g (:h)))))) 


Disjunction Introduction 


(Rule ((:f (goal (Or . :d) for :goal in :context))) 

(Propose-Method '(Method :f (standard-dis-intro)) '(SOI :f) 

(do ((dis :d (cdr dis ))) 

((Null dis)) 

(let ((:car-dis (car dis))) 

(goal-assert :dis ’((Or . :d) . :goal) context '(disj-intro :f)) 
(Rule ((:g :car-dis)) 

(Assert '(Or . :d) '(dis-intro :g))))))) 


Conjunction Introduction 

(Rule ((:f (goal (And :cf . :cr) for :goal in rcontext))) 

(Propose-Method '(Method :f (standard-conj-intro)) '(SCI :f) 

(Assert 

'(conjunctive-goals :cf :cr () ((And :cf . :cr) . :goal) :context) 
' (Use-conj-goals-for-and-intro :f)))) 
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(rule 


(rule 


(Rule 


(Rule 


(Rule 


If-Then-Else Introduction 

j 

((:f (goal (If :p then :q else :r) for :goal in rcontext))) 

(Propose-Method '(Method :f (standard i-t-e)) '(SITEI :f) 

(Assert 

’(conjunctive-goals (implies :p :q) ((implies (not :p) :r)) () 

((If :p then :q else :r) . :goal) rcontext) 
' (use -conj-goals-for-i-t-e : f)))) 


Backward Chaining 


((:f (goal :q for :goal in :context)) 

( :g (implies :p :q))) 

i (Propose-Method '(Method :f (backward-chaining :g)) '(BC :f :g) 
(goal-assert :p '(:q . :goal) :context '(backward-chain :f :g)))) 


Backward Chaining Through If-then-Else 


!((:f (goal :q for :goal in :context)) 

(:g (If :p then :q else :r))) 

(Propose-Method '(Method :f (if-then-back-chain :g)) ’ (ITEBC :f :g) 

| (goal-assert :p ' (:q . :goal) :context '(i-t-e-back-chain :f :g)))) 

((:f (goal :r for :goal in :context)) 

| ( :g (If :p the :q else :r))) 

(Propose-Method '(Method :f (if-else-back-chain :g)) '(ITEBC :f :g) 
(goal-assert '(not :p) '(:r . :goal) context '(i-t-e-back-chain :f :g)))) 


Indirect Proof 

((:f (goal :p for :goal in :context))) 

(Propose-Method '(Method :f (indirect-proof)) '(IP :f) 
(Assume '(Not :p) '(Indirect-proof-assumption :f)))) 
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If this leads to a contradiction and if this contradiction actually depends on the 
assumption of (not : p), then the truth maintenance system will determine that the 
assumption is responsible for the contradictioa It will then bring :p in. This will out 
the assumption. This process is called dependency-directed backtracking; it is 
described in [Doyle, 1978] and in [Stallman & Sussman, 1977] . 

Contrapositive Deduction 

(Rule ((:f (Imp!ies :p :q)) 

( :g (Not :q))) 

(Assert '(not :p) '(contrapositive :g :f))) 

(Rule ((:f (goal (Not :p) for :goal in rcontext)) 

( : g (Implies :p :q))) 

(Propose-Method '(Method :f (Contrapositive-chaining :g)) '(CPC :f :g) 

(goal -assert '(not :q) '((Not :p) . -.goal) :context 

'(contrapositive-back-chain :f :g)))) 


DeMorgan's Rules 


(Not (and a b c ... )) => (or (not a) (not b) (not c) ...) 

(Not (or a b c ... )) => (And (not a) (not b) (not c) ...) 

(rule ((:f (not (and . :x)))) 

(let (( :disj '(or . .(mapcar '(lambda (x) '(not ,x)) :x)))) 
(assert :disj '(de-demorgan :f)))) 

(rule ((:f (not (or . :x)))) 

(let ((:conj '(and . .(mapcar '(lambda (x) '(not ,x)) :x)))) 
(assert :conj '(demorgan-demorgan :f)))) 
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Negation and Quantifiers 

(Not (For-all :vars :p :q)) < = > (There-is :vars :p such-that (not :q)) 

(Not (There-is :vars :p such-that :q) < = > (For-all :vars :p (not :q)) 

(Rule (( : f (not (For-all :vars :p :q)))) 

(Assert '(There-is tvars :p such-that (not :q)) 

1 (negated-for-al1 :f))) 

(Rulej((:f (not (there-is :vars :p such-that :q)))) 

! (Assert '(For-all :vars :p (not :q)) 

'(negated-there-is :f))) 

(Rule ((:f (goal (not (For-all :vars :p :q)) for :goal in :context))) 
(Propose-Method '(Method :f (standard)) '(Quant :f) 

| (goal-assert '(there-is :vars :p such-that (not :q)) 

'((not (for-all :vars :p :q)) . :goal) 
rcontext 

' (negated-for-al1-standard-sub-goal :f)))) 

(Rule (( :f (goal (not (there-is :vars :p such-that :q)) for :goal In :context))) 
| (Propose-Method '(Method :f (standard)) '(Quant :f) 

(goal-assert '(for-all :vars :p (not :q)) 

'((not (there-is :vars :p :q)) . :goal) 

:context 

'(negated-there-is-standard-sub-goal :f)))) 


Section 4.3: Closing The Reflexive Loop 

So far I have shown the use of the task agenda only in the context of theorem 
proving. However, the protocol shown above is actually the way REASON does 
anything which needs to be open to introspective control. Tasks other than theorem 
proving goals are entered into the system by making a task assertion which is treated 
in much the same manner as the goal assertions. Such assertions stimulate the 
proposal of methods; methods are chosen by the acceptor just as was shown above. 

Frequently some partial ordering must be imposed on the execution of tasks. 
This is done by asserting a control-flow assertion mentioning the two tasks which are to 
be ordered. Similarly a task can make information available for use by asserting that 
some object is one of its outputs. This information can be propagated to other tasks 
by the assertion of data-flow assertions which mention the output port of the first task 
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and an input port of some other task. 

Of course this is just the primitives which are used to describe programs in the 
plan diagram formalism!! In fact, I am currently working on building a catalogue of 
useful plans for use by REASON itself. These will be coupled with a set of rules 
which state that a useful way to accomplish some task is to apply one of the plans 
from the catalogue. Of course these plans create sub-tasks and REASON will have to 
chose methods to accomplish each of these. However, it is often the case that there 
are is an a priori good choice for some of the sub-tasks of a particular plan. Thus, 
extremely useful pragmatic information can be provided to the acceptor by building 
rules which analyze the history of method and plan selection and use this analysis to 
select methods. This is roughly the approach followed in [McDermott, 1977], 

Although this is so far past the current development of REASON that it now 
seems to be science fiction, there is yet another advantage to this approach. 
REASON is itself a program written to analyze programs; the language in which a 
substantial part of REASON is written is the language it is capable of analyzing. 
Therefore, it is possible for REASON to analyze itself!! (At least in principle, it is 
possible). 

In later chapters, I will often refer to REASON’S protocols. These are sets of 
tasks to be entered into the task agenda; they are represented in the plan language. 
In the next section I will develop some more representations used in the reasoning 
system; I will then turn to a deeper look at the plan language. 


Section 4.4 1 Equality, Reference and Anonymous Objects 

If one wishes to show that a program has a certain property one must show that 
whatever inputs the program is given, it will still behave in accordance with the 
property. The method used in REASON is to evaluate the behavior of the program 
when presented with typical inputs. Anonymous Objects [Hewitt, 1975], 
[Rich & Shrobe, 1976], [Moore 1975], (they are called formal objects in 
[Sussman, 1975J are used to represent such typical inputs. An anonymous object is 
one whose identity is unknown in the sense that given an anonymous object and any 
other object, it is a priori unknown whether or not the two objects are identical (in 
the sense of being the same object). 
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Anonymous objects provide a convenient stand-in for unknown information of 
various kinds. For example, suppose we wanted to say that the third field of the 
record input to procedure-i is a sorted list If we did not know exactly what item was 
input to procedure-1 we would have to make up some token to stand for that item and 
similarly for the third field of this record. We might do this as follows: 


(input the-record procedure-1 Anon-1) 
(third-field Anon-1 Anon-2) 


(sorted-list Anon-2) 

Notic e, however, that the first two of these predicates are functional, they uniquely 
determine their last argument It is, therefore, possible to use a more concise 
notation: 


(sorted-list [third-field [input the-record procedure-1]]) 

Each expression in brackets ([ ... ]) is read "the object which satisfies ..." and refers 
to the unique object which could appear in the final position of the equivalent 
predicate. In fact, such reference expressions can be constructed for predicates which 
are known to be functional in any positioa For example, if we knew that there were 
a unique list which contains entry-i as a member, we could refer to this list as follows: 

[Member : 1 ist Entry-1] 

in wiich the variable :list indicates the position of the statement which is being 
refened to. The reference expressions above are further abbreviations of this notation 
in which the last position is the variable and is by convention simply dropped 

Whenever REASON asserts a statement with reference expressions in it, it 
atten pts to resolve the references. Reference resolution involves two stages: First, if 
there is an object which satisfies the reference expression, that object is substituted for 
the reference expressioa Second, if no such object exists, an anonymous object is 

created to satisfy the reference expressioa For example, suppose the following is 
asserted: 


For 
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F-0 (Left pair-1 [right pair-2]) 

To process this assertion, REASON must resolve the reference expression 

[right pair-2] 

Le. it must find an assertion matching the pattern 

(right pair-2 :obj) 

There are two cases. Suppose the data-base already contained the assertion: 


F-l (Right pair-2 The-Answer) 

Then the processing would be completed by asserting: 

F * 2 (Left pair-1 The-answer) (Reference-Resolution F-0 F-l) 

If, however, the data-base contained no assertion matching the pattern 

(Right Pair-2 :Obj) 

then the system would create the anonymous object object- 1 , and assert that it satisfies 
the reference expression. Notice that this assertion is not an assumption since it is 
not really saying anything new. The reference expression itself only says that there is 
some object satisfying the expression; resolving the reference by creating the 
anonymous object merely gives this object a name. Since the anonymous object 
created to resolve the reference might be equal to any other object, this new assertion 
cannot be false; therefore, it is justified as a premise, Le. its truth does not depend on 
the truth of any other assertion. 

Since resolving the reference expression creates a new assertion, processing may 
now proceed as above. 
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(Right pair-2 OBJECT-1) (Reference-resolver) 

(Left pair-1 OBJECT-1) (Reference-Resolution F-0 F-2) 

ourse, there is no restriction on the nesting of reference expressions, so the 
ssing is recursive. 


Identification 


The use of reference expressions raises the possibility that we might wind up with 
two distinct names for the same object For example, in resolving the reference 
expression above we created the anonymous object object- 1 to stand for the right part 
of p.iir-2 and from this we deduced that the left part of pair-i is also object-1. 
However, suppose that we had the following assertion in the data-base: 

(Left pair-1 Left-55) (some-justification ...) 

Since a pair can only have one left part, it must be the case that left-55 and object-i 
are jhe same object We are then faced with the problem of what to do with these 
two. lames for the same thing, Le. the problem of handling equality. REASON uses a 
rather unusual tactic in this situatioa The standard tactic in most reasoning systems 
is to build up equivalence classes of equal objects. This however, imposes a price 
when searching for a match since one must check for variants of the desired assertion 
using any possible representative of the equivalence class. REASON instead, 

elimihates this possibility by doing the work in advance; it makes one of the objects 
"disappear". In the current example, there is really no further use for the name 
object-1, since it was merely created as a stand-in when we lacked the information to 
know what the right part of pair-2 was. However, we have now deduced that 
infor nation, so the stand-in is unnecessary. 

Since we have learned that object-i is really left- 55 , we can substitute left-55 for 
objec -i in any assertion in which object-i occurs. This process is called identification. 
To nake this possible, REASON maintains an index of which assertions the various 
objec ts occur in; the index is represented by assertions of the form 

(Occurs-in <object> <fact-name>) 
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Needless to say, these assertions are not indexed with more occurs-in assertions. Every 
time a new assertion is added to the data-base, this index is updated When an 
identification is required, it is then simple to retrieve the appropriate assertions and 
make the substitutions. 

However, this process as explained so far would result in another problem. 
Namely, every assertion mentioning object- 1 is now parallelled by an equivalent 
assertion mentioning left- 55 . It would be wasted effort for both of these assertions to 
be retrieved every time some information was desired. REASON, therefore, maintains 
a mark on each assertion, called the utility mark which serves a function similar to 
that of the in-out mark. If an assertion has its utility mark set, then it is regarded as 
being useless, no rule will trigger on it and it will not be retrieved by a normal fetch 
request However, it is still regarded as being true. 

As REASON goes through the identification process, it sets the utility mark of 
each assertion which mentions the anonymous object being identified away (object-1 in 
this case). Each new assertion depends on both the 10 assertion and the original 
assertion from which it was built In our current example, we have: 


F-2 

(Right 

pair-2 

OBJECT-1) 

F-3 

(Left 

pair-1 

OBJECT-1) 

F-4 

(Left 

pair-1 

Left-55) 


As noted, f-3 and f-4 imply that object-i and left-55 are identical Thus, an 10 
assertion is derived, initiating the identification process. The following assertions 
result: 

F-5 (ID OBJECT-1 Left-55) (Part-Identification F-3 F-4) 

F-8 (Right pair-2 Left-55) (Identification F-2 F-5) 

In addition, both f -2 and f-3 will have their utility mark set The following rules 
implement this process: 
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(trig 


ber-rule 


(( :f (Id :obj-l :obj-2)) 

(:g (occurs-in :obj-l :fact-l))) 

{set-utility-mark :fact-l 'useless) ; mark the fact useless 
(let ((:new-f act (subst :obj-2 : obj-1 :fact-l))) 

(assert :new-fact (identification :f :g)))) 


(rule ((:f (part :obj-type :part-name)) 

( :g (type :obj-type :obj))) 

(rule ((:h (:part-name :obj :part-l)) 

(:i (:part-name :obj :part-2))) 

(or (eq :part-l :part-2) 

(assert (id :part-l :part-2) 

(part-identification :f :g :h :i))))) 


It is important to understand the distinction made here between the utility mark and 
the notion of in and out. In and out deal with belief (or logical relationships) while 

the utility mark is strictly an issue of control (of heuristic value). A fact which is in 

but whose utility mark is set is still regarded as true (or believed) even though it will 
be ignored. This is crucial since the justification for fact f-s above is f- 2, a fact 
whose utility mark is set. If f-2 were regarded as not being believed (as opposed to 

simp y not being useful) then f -8 would have no support and would itself be out. A 

fact whose utility mark is set may support belief in other facts although its presence 
will otherwise be ignored. 


Whenever the truth maintenance system notifies REASON that the belief status 
of a|i id assertion has changed from in to out , REASON will remove the utility mark 
each assertion which had previously been marked. This situation arises 
[ently in hypothetical reasoning, when for sake of argument the system 
les that two objects are identical, leading to an identification process. Later 
the system retracts this assumption, the id assertion will become out removing 
support for the covered assertions. When the utility mark of an assertion is 
remclved, the system will run any rule which matches the assertion but which has not 
yet executed. 
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Section 4.5: Situational Logic 

So far I have ignored the need to represent the temporal behavior of programs. 
The temporal nature of a fact is indicated by tagging an assertion with a situation tag 
[McCarthy, 1968] indicating when that assertion is belie :d to be true; different points 
in time are represented by different situation tags. Thus, we might write: 

((First list-1 obj-l) situation-1) 

((First list-1 obj-2) situation-2) 

to indicate that the first object in list-i is obj-i at one point of time while it is obj-2 
at another. This does not imply that obj-i is identical to obj- 2 ; the actual rule for 

identification used in REASON requires that the situations of the two assertions be 
identical. 

It is often the case that we need to make reference expressions within this 
temporal notation. This is indicated with a temporal reference expression which is 
denoted using braces ({ ... }). For example: 

((First list-1 {[first list-2] situation-2) ) situation-1) 

says that the object which is the first element of list- i in situation-i is also the first 
element of list -2 in situation- 2 . Notice that it does not follow from this that there is 
any situation in which the first element of list-i is ever the same object as the first 
element of list- 2 . A temporal reference expression has two parts: the assertion 
expression and the situation expression; either of these may be a simple reference 
expression. Temporal reference expressions are handled in essentially the same way as 
simple reference expressions discussed above. 

Some assertions are trans-situational in that they relate assertions or objects from 
different situations, id assertions are an obvious example of this. If two objects are 
identical, then they are identical in all situations (for all time as it were). Thus, io 
assertions are never situationally tagged. 
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Logical connectives may also be used to build trans-situational assertions. For 
example: 


is tra 
facts 


reaso 

of t 
P^g 


(Or ((first list-1 obj-l) si) ((Rest list-1 obj-2) s2)) 


ns-situational. It is not true in any situation, but rather is an assertion relating 
in different situations. These will be important in chapter 11 where I discuss 
Ining about side effects. 


REASON also allows assertions to relate the states of objects at different points 
ime. Suppose we wished to describe the behavior of the MACLISP nreverse 
am which reverses a list by changing the pointers in its cells. This program 
works by side-effect; we want to say that the list which is the output of this program 
is the reverse of the list which is the input However, we are talking about the same 
list in both cases since the program works by side-effect The output cell is the one 
which was the last cell of the input list; after the nreverse program has run, this cell is 
the head of the reversed list Suppose that si is the situation just before the nreverse 
program executes and S 2 is the situation just afterwards. We can then write: 


The 
is re 
exprq 
the , 
each 


(Reverse <[1 ist-1 sl]> <[list-2 s2]>) 


Expressions within angle brackets (<[ ... ]>) is called an object-state expression. It 
d as "the state of ... in situation ... ". If an assertion mentions only object-state 
ssions and the situation part of each such expression is the same situation, then 
ssertion is equivalent to a situationally tagged assertion mentioning the objects of 
object-state expression and tagged with the common situation tag. 


asser 
by it|| 
the 
the 


(P <[xl sl]> ... <[xi sl]> ... <[xn sl]>) 

< = > 

((P xl ... xi ... xn) si) 

Notice that the reverse assertion above is not reducible to a simple situationally tagged 
ion. However, consider what would happen if the reverse assertion were replaced 
s definition. We define reverse recursively, saying that one list is the reverse of 
other if the first object of one is the last object of the other and if the rest of 
first list is the reverse of the fragment of the second list beginning with the first 
objeqt and continuing up to the last (I will be more specific about how such 


For Complex 


Program Understanding 



94 


Explicit Control and The Task Network 


definitions are stated in chapter 10). We would then obtain the following; 

(Reverse <[11 Sl]> <[12 s2]>) 

<=> (And (First <[11 sl]> [last <[12 s2]> ] ) 

(Reverse [rest <[11 sl]>] [leading-fragment <[12 s2]> ]}) 

this will lead to reference resolution as shown earlier. However, as we begin to 
resolve the references we will see that many of the expressions are simple reference 
expressions (i.e. without situational tags) which involve only object state descriptions 
from a single state. For example, from the first clause we obtain the following; 


[last <[12 s2]> ] 

Using the rule stated above this is resolved to; 


((last 12 anon-1) s2) 

and the value of the reference expression is anon-i. Thus, following the same rule, the 
enclosing clause becomes; 

((first 11 anon-1) si) 

If we continue this process we will ultimately wind up with only simple situationally 
tagged assertions. Actually, we also wind up with a second trans-situational reverse 
expressioa However, by induction, this will also lead to a set of simple situationally 
tagged assertions, none of which are trans-situational If a defined relation including 
object-state descriptions can be reduced to simple assertions which are not trans- 
situational, then the relation makes sense as a trans-situational assertion, reverse is 
such a relation. Membership in a data-structure is not; an examination of the 
definition of list-membership for example, shows that any trans-situational use of 
membership is incoherent 

A similar reduction can be applied to trans-situational assertions built from 
logical connectives in which each clause is tagged with the same situatioa 


Dependency Directed Reasoning 




4.5 Situational Logic 


(Or (PI si) ... (Pi si) ... (Pn si)) 

< = > 

((Or PI ... Pi ... Pn) si) 


A similar rule applies to negation: 


(not (P si)) <=> ((not P) si) 
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Chapter 5: Describing Programs 

I will use two distinct methods of describing program segments. The first of 
these, called specs, is a formalism for specifying segment's input/output behavior. 
The second, called plan-diagrams is used to build a complex segment by connecting 
together simpler ones. Intuitively, the specs represent the properties of the program to 
be proved and the plan diagram represents the program. Analysis consists of showing 
j that the behavior which results from a plan diagram is that required by the segment’s 
j specs. 


Section 5.1: Specs - I/O Descriptions 

Simple specs consist of 4 sets of clauses: Inputs, Outputs, Expects and Asserts. 
The first two of these are simply lists of internal names or ports for the data objects 
which are the inputs (outputs) of the segment being specified The expect clauses are 
a set of requirements which must be satisfied at the time the segment is applied to its 
inputs. Typically these are type constraints or simple relationships between the input 
objects. Finally, the assert clauses are a set of conditions which are promised to hold 
immediately after the segment has finished its execution The assert clauses may 
mention both input and output objects, providing a convenient method for describing 
side-effects on the input objects. 

We can use the specs formalism to specify a program which calculates the fringe 
of a tree as follows: 


(defspecs fringe 
(Inputs: the-tree) 

(Expect: (Object-type the-tree Binary-tree)) 

(Outputs: the-fringe) 

(Assert: (Object-type the-fringe List) 

(For-all (:the-node) (leaf-node the-tree :the-node) 

(member the-fringe :the-node)) 
(For-all (:the-node) (member the-fringe :the-node) 

(leaf-node the-tree :the-node)))) 
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Spec 


clauses are written in a variant of the predicate calculus which uses the pattern 


matching syntax of artificial intelligence languages and which uses the situation tag 


notat on of the situational calculus [McCarthy, 1968]. The identifiers preceded by 
colon; (e,g. : the-node) are variables; thus, the two quantifiers say that every leaf node 
of the tree is represented in the output of fringe and conversely that only the leaf 
nodes are represented. Where it is possible to unambiguously omit the situation tag 
on a predicate we do so. This is almost always possible, since the use of distinct 
input and output names for the same object defines which situation is meant For 
exam )le, the first clause of the first quantifier above only mentions input objects and 
is, therefore, taken to apply in the input situation. The second clause refers to an 
output object and, therefore, refers to the output situation. In cases where this in not 
possible the two special symbols *before* and *after* are available as names of the 
input and output situations. When specs are used in the symbolic evaluation process, 
tlt^j s, mbolic evaluator defaults in the appropriate situational tags. 

Specs may also have a case structure which reflects the ability of the segment to 
cause control branching. This is done by adding case clauses. For example a test 
which checks whether a node is a leaf node can be specified as follows: 


(defspecs leaf? 

(inputs: the-node) 

(expect: (Object-type the-node binary-tree-node)) 
(case-1: 

(when: (Object-type the-node Leaf))) 

(case-2 

(when: (not (Object-type the-node Leaf))))) 


This 
not 
be s 
there 
cases 


says that when the input node is a leaf we take one control branch and when ifs 
v e take the second branch. As above, the segment has expect clauses which must 
ajtisfied. This segment produces no outputs and has no side-effects. There are, 
ore, no outputs or assert clauses. Segments have any number of cases and these 
may have outputs and assert clauses nested within them. This allows us to 
specify complicated segments which create control branches as well as producing 
outptts. A lookup routine for a complex data-structure might have such specs. 
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It is often necessary to state that several segments share the same I/O behavior. 
One reason for this is that there are tasks for which several distinct algorithms exist; 
these different algorithms lead to distinct segments, but their specs are identical 
There is a second need for saying that different segments have identical I/O behavior. 
Consider the following code for the fringe program: 

(defun fringe (tree) 

I (fringe-1 tree nil)) 

I 

(defun fringe-1 (tree acc) 

(cond ((leaf? tree)(cons tree acc)) 

(t (fringe-1 (left tree)(fringe-1 (right tree)))))) 

Notice that there are two recursive calls to fringe- i. Thus, there are three instances 
of fringe which we might want to distinguish for some purposes while still maintaining 
i the awareness that these segments have a common I/O specification. 

The name in a defspecs statement is therefore regarded as a spec-type, rather 
than as the specs for any particular segment If we need to indicate that a segment 
has the specs in a defspecs statement, we state that its spec-type is the spec-type- 
name in the defspecs clause. Thus, we could say that the two recursive calls in the 
fringe program have the same I/O behavior as follows: 


(spec-type left-fringe fringe) 

(spec-type right-fringe fringe) 

where left-fringe is the recursive call to fringe for the left sub-tree and right-fringe is 
the recursive call for the right sub-tree. This does not yet allow us to state that 
these two instances of fringe have identical internal structure. That is the subject of 
the next sectioa 
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Section 5.2: Plan Diagrams 

Plan diagrams are a method of building a program segment by linking together 
the behaviors of smaller segments. In talking about a plan diagram there will always 
be a main segment (i.e. the segment described by the plan diagram) and a set of sub- 
segments which are being linked to form the main segment In turn, some of these 
sub-segments will have plan diagrams and internal segments of their own. Thus, there 
may be several levels of aggregation within a plan diagram. 

Segments within a plan diagram may be joined by two kinds of links: data-flow 
and control-flow. Since specs give a unique name to each input and output object of 
a segment, we may specify how data-flows between segments by stating which object- 
nam< of the first segment flows to which object-name of the second For example 
two ;ub-seginents at the same level of detail might be linked by having the output of 
one llow as an input to the other. 

(dataflow (output <segment-id-l> <object-name-l>) 

(input <segment-id-2> <object-name-2>)) 

The data-flow above is referred to as an output-input link; this is the only type of 
data-flow link which can connect two sub-segments of a common plan. When we are 
concerned with the links between the main segment and its sub-segments there are 
two 3ther kinds of data-flow links: Input-Input in which an input of the main segment 
is passed directly to a sub-segment as one of its inputs, and Output-Output in which 
the output of a sub-segment is passed to the main segment as one of its outputs. 

| Control-flow links are included for two purposes. A simple control-flow link 
state; that one segment must finish its execution before the other segment may begin 
to execute. This is included so that segments with side-effects can be properly 
ordered to avoid destructive interference. Data-flow links imply an ordering 
relationship as well, since a segment may not execute until all its inputs have arrived 
Other than these constraints there is no ordering imposed; plan diagrams are always 
interpreted in a (pseudo) parallel manner, even though I use them to analyze the 
behavior of sequential processes. 


i 
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The more complicated use of control-flow links is to specify where control will 
go from a segment whose specs split into cases. Conditional-control- flow links connect 
a particular case of a segment to its succeeding segment Thus, if a segment has two 
cases (a typical test) there will be one conditional-control-flow link for each case 
leading to that segment which should next be evaluated if that particular case is 
applicable. A segment which terminates a conditional-control-flow link cannot execute 
unless the initiating case of the link is applicable. 



Conditional-Control-flow Links 


It should be noted that control-flow links are not connected to a particular port of a 
segment in the way that a data-flow is. The symbolic interpreter which I will 
describe in the next chapter interprets the control-flows, since they are extrinsic to the 
segment The presence of a control-flow is in no way related to any intrinsic 
specification of the segment 
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splittj 

split 

from 


pne final tool used in plan diagrams is the join which is the inverse of a case- 

E ig segment. A join merges several distinct control paths produced by a case 
nto a single synthesizing control path. The join takes a set of input objects 
each control path and produces a set of output oojects on the synthesizing 
contrlbl path. It has a set of input expectations specifying conditions which must hold 
true )f the input objects flowing to it from each control path and assert conditions 
about the merged output objects. Since the control paths which terminate at a join 
are required to originate from a common case splitting segment, it is impossible for 
more than one of these paths to be active at any one time. Thus, the join is 
applicable when one of its incoming control-flow links is active and the associated 
input objects are available. 

The fringe program employs a typical use of the join, fringe tests whether the 
curre it node is a leaf. If so, the leaf is accumulated. Otherwise, recursive calls are 
made on the left and the right nodes, producing an accumulation. These two controls 
paths and their respective accumulations are then synthesized by a join which states 
that whichever path was taken, the accumulation returned includes all the leaf nodes 
of th; input node. 

We may use these notions to represent the fringe program diagrammatically as 
follows: 
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Schematic Plan Diagram For Fringe 


Notice that in the above diagram, the "railroad track" lines represent control-flow, 
while the solid lines represent data-flow. 

This diagrammatic representation of the program has a direct translation into 
specifications, data- and control-flow assertions as shown: 
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(dataflow (Input fringe the-tree) 

(Input leaf? the-node)) 

I 

(dataflow (input fringe the-tree) 

(input process-non-leaf the-tree)) 

i 

(dataflow (input fringe the-accumulation) 

(input process-non-leaf the-accumulation)) 

(dataflow (input fringe the-accumulation) 

(input accumulate-fringe the-accumulation)) 
(dataflow (input fringe the-tree) 

(input accumulate-fringe the-new-element)) 

(dataflow (input process-non-leaf the-tree) 

(input left the-tree )) 

(dataflow (input process-non-1eaf the-tree) 

(input right the-tree )) 

(dataflow (output right the-node) 

(input right-fringe the-tree)) 

(dataflow (input process-non-leaf the-accumulation) 
(input right-fringe the-accumulation)) 

(dataflow (output left the-node) 

(input left-fringe the-tree)) 

(dataflow (output right-fringe accummulation) 

(input left-fringe the-accumulation)) 

(dataflow (output left-fringe accumulation) 

(output process-non-leaf accumulation)) 

(dataflow (output process-non-leaf accumulation) 

(input (join-fringe case-2 the-accumulation))) 
(dataflow (output accumulate-fringe the-accumulation) 

(input (join-fringe case-1 the-accumulation))) 

(dataflow (output join-fringe the-accumulation) 

(output fringe the-accumulation)) 

(conditional-control-flow 

((test-leaf case-2) process-non-leaf)) 
(conditional-control-flow 

((test-leaf case-1) accumulate-fringe)) 

(control-flow accumulate-fringe (join-fringe case-1)) 

( control-flow process-non-1eaf (join-fringe case-2)) 
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(spec-type test-leaf leaf?) 

(spec-type left-fringe fringe) 

(spec-type right-fringe fringe) 

(spec-type accumulate-fringe cons) 

If two segments are internally identical, i.e. if they have identical internal 
structure then we say that they have the same pi an-type. It follows that if segment -1 
and segment -2 are of the same plan-type then they are also of the same spec-type. 

A plan type is defined using six clauses: 

(i) A list of sub-segment names (we will often refer to these names as roles of the 
plan). 

(ii) A set of type constraints on the sub-segments, Le. a list of what plan-type or 
spec-type constraints they satisfy 

(iii) A set of data-flow links. 

(iv) A set of control-flow (and conditional-control-flow) links. 

(v) A set of input names. 

(vi) A set of output names. 

This may be specified as follows: 


(defplan fringe 

(sub-segments: test-leaf left-fringe right-fringe 
left right accumulate-fringe) 

(constraints: (spec-type test-leaf leaf?) 

(plan-type left-fringe fringe) 

(plan-type right-fringe fringe) 

(spec-type accumulate-fringe cons) 

(spec-type left left) 

(spec-type right right)) 

(flow-diagram: (dataflow ... ) 

... )) 

If two segments have the same plan-type, then their internal structure is identical 
to the degree of detail specified in the plan diagram. Thus, their internal temporal 
behavior is identical. Notice that the plan diagram for the plan-type fringe includes 
two sub-segments whose plan-type is also fringe. It follows that if we wish to prove 
some temporal property of the fringe plan-type we may do so by an inductive 
argument, assuming that this property holds of the two sub-segments of plan-type 
fringe and deriving the desired property of the main segment It is important to 
remember the distinction between plan-types and spec-types. Knowing a segment's 
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spec-)type will not help in inductive proofs of it internal temporal properties; spec-type, 
in contrast to plan-type, is strictly concerned with I/O behavior. 


For Complex Program Understanding 





106 


A Symbolic Interpreter for Plan Diagrams 


Chapter 6: A Symbolic Interpreter for Plan Diagrams 

In this chapter I will describe how REASON proves properties of a plan diagram 
through a process called symbolic interpretation [Rich & Shrobe, 1976], [King, 1976], 
[Smith & Hewitt, 1975], [Yonezawa, 1977]. This process is extremely thorough, 
recording all dependencies between the various statements in the plan diagram and in 
the sub-segments' specs. The mechanisms explained here lay the groundwork for being 
able to describe the internal temporal behavior of a segment; this will be used in the 
!. next chapter where I will develop a more powerful set of descriptive tools used in the 
process of plan recognition. 

| 

Recall from Chapter 4 that a situation is defined to be a point of time during a 
computation, and that, in general, facts are true in a particular situation. 

j (<Assertion> (Situation)) 

eg- ((First list-1 object-1) Situation-1) 

An application represents the result of applying a segment to a set of input 
objects which satisfy the expectations of the segment, yielding a set of output objects 
| which satisfy the assert clauses of the segment An application consists of (0 a 

segment, (ii) a set of input objects and a mapping of these objects to the input names 
of the segment, (iii) a set of output objects and a mapping of these objects to the 
output names of the segment, (iv) an input situation, and (v) an output situation. 
This is represented as follows: 

j (i) (Segment-part (application) (segment-name)) 

(ii) (Input (application) (segment-input-object-name) (object)) 

(iii) (Output (application)(segment-output-object-name) (object)) 

(iv) (Input-situation (application) (situation)) 

(v) (Output-situation (application) (situation)) 

Each of these relations is a function (i.e. uniquely determines its last argument); we 
may, therefore, use such descriptions to refer to an object unambiguously, using the 
bracket notation defined in Chapter 4: 

(comes-before [input-situation application-1] situation-5) 
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durin 

situat 


whicjh says that the input situation of application-i precedes situation- 5 . 

A plan diagram for a segment determines those applications which will take place 
the segment's execution. It also determines the set of input and output 

ons of these applications. Finally, the plan diagram determines a partial 

order ng on these situations which represents the minimal ordering constraint on 
segment execution consistent with correct execution. This information can be made 
explicit by a symbolic interpretation of the plan diagram. 

Given a set of input objects for a main segment we may interpret the plan 
diagram in the much the same way as a LISP interpreter interprets its code. 
However, since our concern is with the general behavior of the plan diagram, the 
objects will be symbolic values representing typical inputs. Thus, any behavior 
can be shown to result from applying the segment to these symbolic objects 
hecessarily also be true when applied to any actual input 


input 

whichl 

must 


i 


set oft 
parts 


have so far shown specs and plan diagrams as "packages", Le. as a single large 
statements. However, in order to build dependencies correctly, the various sub- 
of these packages must be accessible as individual statements. REASON, 
therefore, expands plan diagrams and specs into an internal format in which each 
separate idea is represented as an individual fact We will see how these are used as I 
explaip the symbolic evaluation process. 

J he interpretation begins by creating an anonymous object to stand for the 
t application of the main segment For simplicity this name is always chosen as 
the p an-type name of the diagram. REASON then proceeds, assigning the input 
objects to the appropriate input ports of the main segment As each object is 
assigned to an input port, the symbolic interpreter adds an assertion to the data-base 
stating the assignment For example, if list-i is the input object matched to the 
input port the-current-list of application a-i then REASON would assert 

(Input A-l The-Current-List List-1) 


input 
situati 
substii) 
situati 


he expect clauses are then substituted into, replacing each of the segment's 
port names by the actual input object which is assigned to that port A 
ian is created to serve as the input situation of the main segment and the 

uted expect clauses of the main segment are assumed to hold in this input 
On. 
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Each input port of the main segment is connected via at least one data-flow link 
to an input port of some sub-segment Intuitively, the data-flow link transports the 
object from the specified port of the main segment to that of the sub-segment 
Whenever the symbolic evaluator sees that a object is bound to a port which is 
connected to the initiating side of a data flow link, it simulates the data-flow by 
assigning the same object to the port which terminates the data-flow. The 
justification for the assertion stating this assignment points to the data-flow link and 
the assertion stating the assignment of the object to the initiating port For example, 
if we had the following: 

| F-l (Input A-l The-Current-List List-1) 

F-2 (Segment-Part A-2 Sub-Seg-2) 

F-3 (Data-flow (Input A-l The-Current-List) 

(Input Sub-Seg-2 The-New-List)) 

then REASON would assert: 

F-4 (Input A-2 The-New-List List-1) (dflow F-l F-2 F-3) 

When all of a sub-segment's input ports have been assigned input objects the sub- 
segment is ready for application, an application name is created and asserted to be the 
| application name of the current invocation of the sub-segment 

If the segment's spec-type is provided in the plan diagram then application 
proceeds as follows: First, a situation is created to serve as the input situation of the 
sub-segment, for example: 

F-5 (Input-Situation A-2 Situation-2-In) 

Next, since the expect clauses of the segment's specs are required to be true in this 
input situation, REASON creates a goal to show that each expect clause holds. These 
goals are the expect clauses with the input objects substituted for their corresponding 
input names. Each such goal assertion has a dependency pointing to (i) all of the 
input assertions relevant to that clause, (ii) the spec clause from which the goal is 
built, and (iii) the assertion stating the input situation of the application. If all of the 
goals are satisfied the segment is applicable, otherwise the plan has an error. The 
assertion that the segment is applicable is justified by a dependency which points to 
the satisfied assertions for each expect clause goaL Thus, if sub-seg -2 has expects e-i 
and e-2 and if sub-seg-2 has spec-type spec-3 then the following assertions are created: 
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F-6 

F-7 

F-8 

F-9 

F -10 


(Spec-type Sub-Seg-2 Spec3) 

(Spec-Clause Spec3 Expect Case-0 Clause-1 
(E -1 The-New-List)) 

(Spec-Clause Spec3 Expect Case-0 Clause-2 
(E-2 The-New-List)) 

(Goal ((E-l List-1) Situation-2-In) 
for (Expect-clause-of A-2) in ()) 

(Goal ((E-2 List-1) Situation-2-In) 
for (Expect-clause-of A-2) in ()) 


(ExpClause F-7 F-6 F-5 F-4 F-2) 


(ExpClause F-8 F-6 F-5 F-4 F-2) 


notice the use of the "for" part of the goal assertion to indicate that the higher level 
task from which the goal arose is the symbolic interpreter's expect checking routine. 


wh 


F -20 


F -21 


F -22 


en these goals are satisfied we obtain the following: 

satisfied (goal ((E-l List-1) Situation-2-In) 
for (Expect-clause-of A-2) in ())) 

satisfied (goal ((E-2 List-1) Situation-2-In) 
for (Expect-clause-of A-2) in ())) 

Applicable A-2) (expects-satisfied F-21 F-20) 


When the segment is shown to be applicable a new situation is created to serve 
as the segment's output situation. If the segment's specs specify that any of the 
outputs are new objects (Le. created within this segment's execution), then the 
interpreter creates object names for these outputs and assigns then to the appropriate 
output ports. This is done using an output assertion which is similar to that input 
assertion shown above. The assert clauses of the specs are instantiated, replacing each 
(inpui or output) port name by the name of the object assigned to that port The 
appropriate situational tags are also defaulted into these assertions. These instantiated 
assertions are then asserted with justifications which point to the statement that the 
segme nt is applicable, to the spec-type assertion for this segment, to the assertion 
repreienting the actual spec clause from which this assertion is built, and to the 
relevjnt input and output assertions. Suppose that a -2 is determined to be applicable 
and hat it produces an output named out-list. Suppose, further, that the assert 
clause s of this segment specify that its output is to be sorted Then, REASON would 
create the new object out-list -1 to stand for this output, asserting: 
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F-40 (Output-Situation A-2 Situation-2-0ut) 

F-41 (Output A-2 Out-List Out-List-1) 

F-42 (Spec-clause Spec3 Assert Case-0 Clause-1 (Sorted Out-List)) 

F -43 ((Sorted Out-List-1) Situation-2-Out) (Output-Assert F-22 F-42 F-41 F-40 F-6 F-2) 

The output ports of the sub-segment just interpreted are linked to other segments 
via data-flow links. These may terminate at either input ports of other sub-segments 
or at output ports of the main segment If the data-flow link terminates at another 
I sub-segment's input port, the object assigned to the output port of the first segment is 
then assigned to the input port of the second. This process produces assertions like 
those created by the data-flows from the main segment's to sub-segmenfs input ports.. 
For example, if the output of a -2 flows to sub-seg-3's sorted-list input we would get the 
following assertions: 

| F-100 (Dataflow (Output Sub-Seg-2 Out-List) 

(Input Sub-Seg-3 Sorted-List)) 

| F-101 (Segment-Part A-3 Sub-Seg-3) 

| 

I 

F-102 (Input-Situation A-3 Situation-3-In) 

| F-103 (Input A-3 Sorted-List Out-List-1) (dflow F-41 F-2 F-100 F-101) 

If the terminating sub-segment now has all of its input objects bound, it is ready for 
application and we proceed as above. 

If a data-flow link leads from a sub-segment output port to an output port of 
the main segment, then the object assigned to the sub-segmenfs port is transported to 
I the output port of the main segment Assertions and justification like those above are 
created. If object are assigned to all the output ports of the main segment, then 
interpretation of the plan diagram is complete and an output situation for the main 
segment is created. If the plan diagram correctly implemented the specs of the main 
segment, then the assert clause of the main segment should be provable in its output 
situation. Goal statements like those created for expect clauses of a sub-segment are 
created for the assert clauses of the main segment; these goals are justified in a 
manner similar to that above. 
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So far I have assumed that the spec type of each sub-segment is known. 
However, if the segment's spec-type is not known, but rather an internal plan diagram 
is piovided (i.e. we know its plan but not its specs), then the sub-segment is 
inter] >reted recursively; an output situation and a set of output objects will result 
The interpretation then continues as above. If both the specs and the plan diagram 
for a sub-segment are known, REASON first uses the specs in interpreting the outer 
diagram and then returns to the inner diagram, symbolically interpreting it and 
show ng that its specs follow from its plan diagram. As we will see later, this allows 
us to break the task up into smaller pieces; in the case of recursions and loops it 
provides a means for stating a "subgoal invariant" [Morris & Wegbreit, 1977], 

A subsegment which has cases presents additional complexity. Like other 
segments the segment with case-splits may have expect clauses which must be true for 
the segment to function and asserts which are true no matter which case is taken. 
Thes; are called the case-0 clauses; if the case-0 expects cannot be proven in the 
segm ent's input situation an error has been detected. If the case-0 expects are shown 
to b< satisfied, the case-0 asserts may be asserted in the output situatioa However, 
once the case-0 clauses have been proven it is still necessary to show that at least one 
of tie other cases is valid. This is done by iterating over the cases attempting to 
prove the when clauses of each. As each case is attempted, REASON sets the goal of 
show ng that each when clause of the case is provable. If these goals are satisfied, the 
case is applicable : Before starting however, it assumes that the case is inapplicable so 
that unless a proof of applicability is found, REASON prudently assumes that there 
are no applicable cases. 

Each attempted proof of a when clause can lead to one of three results: a proof 
of the clause could be found, a refutation of the clause could be found, or neither of 
the j bove. In many practical cases, the system will be able to know when it has 
reached a case of unprovability; typically the inputs to the main segment of a plan 
diagram are not highly constrained by the expect clauses; for example, a segment 
migh expect a list as input and then test internally for emptiness, taking different 
branches for the two possibilities. In such cases the system can determine that it 
cannot know whether the input list is null or not; instead REASON will immediately 
engape in a case-split analysis. This avoids the wasted effort of attempting to make 
impbjisible proofs. 
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If proofs can be found for all the clauses of a case, then the case is applicable. 
REASON asserts the case to be applicable with a justification pointing to those facts 
which satisfied the when goals. The assert clauses of the case are added to the output 
situation and justified as above. If a when clause of a case is refuted, the case is 
declared to be inapplicable with a justification pointing to the refuting fact The next 
case is then tried. 

The specs used in REASON for case-splitting segments assumes that the cases are 
ordered sequentially, i.e. case -2 can only be considered if case-i is inapplicable, and 
similarly for the remaining cases. Thus, the goal of showing the applicability of case-2 
includes a subgoal that case-i is not applicable, case-3 includes the two goals that 
case-i and case -2 are not applicable. However, REASON will not attempt a case 
unless it already knows that the prior cases are not applicable (or unless they are of 
unknown applicability , as I will discuss next). Therefore, REASON already knows the 
results for the previous cases and includes these in the dependencies supporting the 
assertion which invoked the conjunctive goal mechanism. This builds up a 
justification structure which guarantees that no more than one case can have its 
applicable assertion in at the same time. Thus, a segment with three cases would 
have justifications like the following (Note: wavy lines indicate non-monotonic 
dependency). 
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CASE-1 


(Satl 

(Sat 

(Apf| 


(Not 

(Ref 
(Ref 


sfied Expect-11 
sfied Expect -12 


1icable Case-L) 


(Applicable Case-1) ) (No t (Applicable Case- 2))i( Not (Appli 

[t.d 


uted Expect-12) 


CASE-0 


(Satis 

(Satis 


deper| 
at a 
(disjt| 
that 
a tirtt 


some 
claust 
least 
cases 
deperj 
inputs 



CASE-2 

(Satisfied Expect-21K. 
(Satisfied Expect-22)^ ) 

/ 

(Applicable Case-2). 


CASE-3 

(Satisfied Expect-31 
(Satisfied Expect-32) 


(Applicable Case-3) 



cable Case-3)) 




(Refuted ExpecT-21) 
(Refuted Expect- 


(Refuted Expect-31) 
(Refuted Expect-32 


(Or (Applicable Case-l)^ 
(Applicable Case-2) 
(Applicable Case-3))) 

(Applicable Seg-1) 

% 

(Not (Applicable Seg-1)) 



(Applicable* Case-0 hi)/^( Not (Applicable Case-0)) 


fied Expect-01) 
fied Expect-01) 





(Refuted Expect-01) 
(Refuted Expect-02) 


Support Structure For Case-Splitting Segment 
(Notice that this is an "and-or" graph. Individual justifications include 
dence on several facts at once (conjunction is indicated by lines joining together 
arrow) while several justifications may independently support the same fact 
nction is indicated by separate arrows pointing at the same fact). Also notice 
he dependencies guarantee that at most one case will be considered applicable at 
le. 

However, the normal circumstance is that each case (except the last) will have 
when clause which can be neither proved not refuted; we then say that the 
is of unknown truth value, A case which contains no refuted clauses and at 
one clause of unknown truth value is said to be of unknown applicability. These 
reflect the possibility that a test might sometimes succeed and sometimes fail, 
ding on the input data. Since we are interpreting the plan on symbolic (typical) 
most segments with case structure will have cases of unknown applicability. 
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If a case has unknown applicability then REASON first considers the possibility 
that the case is applicable, assuming that all its clauses of unknown truth value are 
true. These are justified by a non-monotonic dependency structure of some 
complexity, the purpose of which is to allow the system to select between the cases 
later. For the moment I will ignore all aspects of the justifications which are not 
related to the case-splitting. Suppose that case-i of application A3 has a when clause 
requiring p, and further suppose that p is not provable. We want to set up 
justifications so that we may easily return later to the assumption that case-i is 
applicable, bringing in the assumption that p holds. Also we want to be able to 
switch easily to the assumption that some case other than case-i holds, bringing in the 
assumption (not p). Therefore p is made to depend non-monotonically on (not p). 
Also REASON creates an assertion stating that it should consider case-i and it makes 
p depend monotonically on this assertion. 

F-110 (not P) ; Note lack of 

F-lll (Select Case-1 A3) ; justification 

F-112 P (Case-Split-Assumption (F-lll) (F-110)) 

However, this is not all that must be done. If case-i is not to be considered (as 
would happen when we go on to look at other cases) we would want (not p) to be 
brought in. Actually, if there is more than one unknown clause then we want to 
bring in the disjunction of all such clauses. Assume there is a second when clause q in 


CASE-1. 

Then the justification structure would look like: 

F-110 

(not P ) 

; no justification 


F-lll 

(Select Case-1 A3) 

; no justification 


F-112 

P 

(Case-split-Assumption 

(F-lll) (F-110)) 

F-113 

(not 0) 

; no justification 


F -114 

0 

(Case-split-Assumption 

(F-lll) (F-113)) 

F-115 

(Or (not P)(not 0)) 

(Case-Split-Assumption 

(F-116) (F-lll)) 

F -116 

(Select Case-2 A3) 

; no justification 



If there is a third case, then f -115 should also be brought in whenever this case is 
being considered. REASON adds another justification to F -115 as follows-* 

F-117 (Select Case-3 A3) ; no justification 

F-115 (Or (not P)(not 0)) (Case-Split-Assumption (F-117) (F-lll)) 
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REASON may now consider any case simply by giving the appropriate 
(select case -1 A3) assertion a justification. When it is through considering the case, it 
must remove the justification for the select assertion by retracting the justification 
suppo rting the select assertion. Notice that if no select assertion is justified, then 
none of the assumptions are m, representing the most general case where we have no 
idea *vhich case holds. 

Once REASON has assumed all clauses of unknown truth value for a particular 
case, it will have satisfied all the case's when clauses. The case will then be declared 
applicable and a justification created pointing to all assertions satisfying any of the 
when clauses, including the assumptions justified by the select assertioa The output 
clauses of the case are then asserted in the output situation, each being justified by 
the assertion declaring the case applicable. Thus, the logical relationship between the 
assumptions and the output assertions is represented explicitly in the data-base. 
Findl y, if there are conditional-control-flow links coming from the current case, these 
are c eclared active with a justification pointing to the assertion which declares the 
case applicable. REASON now continues evaluating any segments which terminate the 
conditional-control-flow links leaving the segment until it reaches either a JOIN or the 
outpi t side of the main segment of the plan diagram. 

As REASON goes along the paths started by the conditional-control-flow links, it 
records which cases have yet to be evaluated. Thus, when a terminal segment is 
reached it returns to evaluate the remaining cases. 

It begins by 01 /ring the select assertion for the last case evaluated, removing the 
asser ion's justification. It then justifies the select assertion for the next case. This 
has he effect of assuming the falseness of at least one of those clauses from the 
previous case which had unknown truth value. The inapplicability of the previous case 
follows from this assumption directly (using proof by cases if there is more than one 
claus; of unknown truth value); REASON constructs this proof recording the 
apprc priate justifications. Thus, selecting case -2 will out the applicable assertion of 

CASE-]. 

The next case is then evaluated with its select assertion in; Le. REASON 
inves igates whether the next case's applicability follows from the inapplicability of the 
previous case. If the new case has clauses of unknown truth value, then REASON 
proceeds as above, creating non-monotonic justifications for the current case's 
applicability. If all the clauses of the new case can be proven, then this case is 
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declared applicable. If the case has a clause which is definitely false, the case is 
declared inapplicable; REASON then moves on to the next case. 

If the last case has clauses of unknown truth vilue, then the segment is declared 
inapplicable with a justification pointing at a statement expressing the possibility that 
the unproven clauses might be false. This statement is justified so that it depends on 
the or/mess of the clauses of unknown applicability; if something is changed to make 
these clauses definitely true, the inapplicable assertion will go out. If the last case has 
clauses of unknown truth value, then there is an error which manifests itself as an 
intermittent program bug; if the input data happened to be such that an earlier case 
would succeed then the program would work, otherwise it would fail. Such 
intermittent bugs are among the most distressing problems of programming and it is 
desirable to be able to spot them through the process of symbolic evaluation. 

• Since REASON requires both that at least one case be applicable and that case-« 
be applicable in all circumstances, the final action taken in evaluating a case-splitting 
segment is to assert the disjunction of all the select assertions and to attempt to prove 
the applicable assertion for the segment This is always done by case-splitting the 
disjunction of the select assertions. Thus if there were three cases, we would have: 

F-500 (Or (Select Case-1 A3)(Select Case-2 A3)(Select Case-3 A3)) 

F-501 (Subgoal (And (Or (Applicable Case-1 A3) (Applicable Case-2 A3) (Applicable Case-3 A3)) 

(Applicable Case-0 A3)) 
for ((Applicable A3) ...) 
in (...)) 

F-502 (Show (goal (Or (applicable ...))) 

by (splitting (OR (select ..))) 
for ((Applicable A3) ...) in (...)) 

This proof proceeds trivially; all the justifications have already been built up As each 
select statement is assumed by the case-splitting mechanism, the corresponding case 
becomes applicable and the disjunction in F -501 is deduced by disjunction introduction. 
If the last case had not been found applicable, however, then the appropriate clause 
will not come in and the goal will not be deducible. REASON complains that it has 
found a bug. In any event the final justification structure built up in this process 
looks as follows: 
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(Select Case-1) 


Expect-11- 

Expect-12- 

(not Expect-11) 
(not Expect-12) 


(Satisfied Expect-11) 
■(Satisfied Expect-12) 


"(Refuted Expect-11) - 
►(Refuted Expect-12) 


(Applicable Case-1 )■ 


Not (Applicable Case-1)) 


(Select Case-2) 


>(or (not expect-11) 

^ (not expect-12)) 


►Expect-21 

*Expect-22 


(Satisfied Expect-21 
(Satisfied Expect-22 


(Applicable Case-2)' 


(not Expect-21) - 
(not Expect-22)- 


’(Refuted Expect-21)- 
“(Refuted Expect-22)' 


[Not (Applicable Case-2)) 


(Select Case-3)- 


Expect-31* 

Expect-32 


►(or (not expect-21) 
(not expect 22)) 


(not Expect-31)- 
(not Expect-32)* 


"(Satisfied Expect-31 
(Satisfied Expect-32 

'(Refuted Expect-31)- 
►(Refuted Expect-32)^. 


(Applicable Case-3)- 


iNot (Applicable Case-3)) 


(Or (Applicable Case-1 )(Applicable Case-2)(Applicable Case-3)! 


r(Applicable Seg-1) 


(Not (Applicable Seg-1)) 


CASE-0 


(Satisfied Expect-01 )~\ -(Applicable Case-0) 


[ Satisfied Expect-01 )~\ 
(Satisfied Expect-02)^^ 


(Refuted Expect-01) 
(Refuted Expect-02) 


(Not (Applicable Case-0))« 


(or (Select Case-1 )(Select Case-2)(Select Case-3)) 


Support Structure For Case-splitting With Clauses of Unknown Truth Value 


For Complex Program Understanding 



11 $ 


A Symbolic Interpreter for Plan Diagrams 


When a case is declared applicable its output objects are propagated along 
control-flow links just as for non case-splitting segments. In addition if there is a 
conditional-control-flow link originating at a case then it is active whenever the case 
with which it is associated is applicable. A segment which terminates a conditional- 
control-flow link is ready for application only if all its incoming control-flow links are 
active. 

The only primitive of plan diagrams not yet discussed is the join. When the 

control-flow link and all inputs leading to a case of a join are available, REASON 

creates an anonymous object to stand for the output objects of the join. It then 
creates assertions pairing the inputs to the newly created outputs. The pairings are a 
set of id assertions with the input object and the corresponding output object as 
arguments. Each id assertion is justified by a select assertion stating that the current 
case of the join is active. This, in turn, is justified by the assertion stating that the 
incoming control-flow link is active. Thus, a specific pairing of the join's output to 
an input object can only be made if one of the incoming control-flow links is active. 

However, a control-flow link terminating at a join must trace back to a case of 

a segment at which control was split The join case can be active only if the 

appropriate case of the segment at which control split is applicable. When REASON 
first evaluates a case of a join it examines which segment select statements are irr f it 
then justifies these by a pointer to the case select statement for the join case. 
Selecting a join case then brings in all the assumptions relevant to the particular 
control path which terminates at that case of the joia The select statements for the 
join are quite similar to those for case-splitting segments and may be used in proofs 
by cases to prove various properties of the output objects of a joia This is useful 
since t makes it possible to state properties of the output object without making a 
commitment to which case is active. 

When control reaches a join, REASON does not continue interpreting past the 
join. Instead it returns to any case-splitting segment whose analysis has not yet been 
completed. This will make other control paths active, activating other incoming cases 
of the join. Only when all incoming cases of a join have been activated will 
REASON pursue the paths leading away from the join. Before doing so, however, it 
makes sure that it has cleaned up the evaluation of all prior case-splits so that 
evaluation of the paths leading out from the join does not inadvertently proceed under 
the assumption that only a single case of the case-splitting segment need be 
considered. 
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( Vhen all interpretation is completed REASON attempts to prove that the assert 
> of the main segment are satisfied. Again each clause is translated into a goal 
he reasoning mechanisms of the previous chapter are invoked. If the proofs 
d, justifications are built as before. Thus, when all the goals are proved a 
comp ete dependency network is built, linking every satisfied goal back to the 
pritni ives of the plan diagram upon which the goal depends. These dependencies 
point to data-flow and control-flow links, to input assertions of the main segment and 
to otitput assertions of the sub-segments. 

Bach such proof of a goal can be categorized as either a pre-requisite proof or 
an achieve proof. Pre-requisite proofs are those which establish that a sub-segmenfs 
expet' and when clauses are satisfied. Achieve proofs are those proving the assert 
clau$cs of the main segment If these are summarized to remove the detail, leaving 
only toe connections between specs clauses and flow links then we have what we have 
callec purpose links: 

We see, therefore, that a symbolic interpretation in REASON leads to 
considerably more information than just the statement that the program does what is 
intended. In addition to this data, REASON produces a complete proof and a 
sumir ary of this proof into purpose links which quickly indicate the intermodule 
depdrdencies in the program. Furthermore, this data is so organized that if a crucial 
spec pause is changed then all other sub-segments which depended on this clause will 
be declared inapplicable. This change of spec status will be signalled by the Truth 
Maintenance System as part of its normal wing and oufi ng of facts. REASON 
responds to these notices and informs the user of the exact nature of the problem 
cause! by the change. Purpose links provide a rapid mechanism whereby REASON 
can i ell without a deeper analysis that a proposed change is not safe. Since the 
purpcse links tell whether a spec clause is used in any proof, all REASON must do is 
to ses if the clause is involved in any purpose links. If so, the link tells which 
segnh nts are affected by the change. 
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Chapter 7! An Example of Symbolic Interpretation 

To show how the features developed so far interact in the analysis of a 
moderately complicated algorithm, let us consider how REASON interprets a routine 
for computing the intersection of two sets represented as ordered lists. This algorithm 
runs in linear time by only considering the heads of both lists. If the two heads are 
identical, then that element should be added to the accumulation. If they are not 
identical, then the smaller element cannot also be a member of the other list Thus, 
it can be thrown away and the iteration continued. One possible coding of this 
routine is as follows: 

(Defun fast-intersect (list-1 list-2) 

(do ((Acc ni1) 

(Car-U Nil ) 

(Car-12 Nil) 

(Uid-1 Nil) 

(Uid-2 Nil)) 

((Or (Null 11st-1)(Nul 1 list-2)) 

(Reverse Acc)) 

(Setq Car-U (car list-1) Car-12 (car list-2)) 

(Setq Uid-1 (maknum car-11) Uid-2 (maknum car-12)) 

(Cond 

((Eq Uid-1 Uid-2) (Setq Acc (cons Car-U Acc)) 

(Setq list-1 (cdr list-1) 
list-2 (cdr list-2))) 

((< Uid-1 Uid-2) (Setq list-1 (cdr list-1))) 

(t (Setq list-2 (cdr list-2)))))) 

As we mentioned before, the LISP code is first analyzed by a surface flow analyzer 
which abstracts out many of the details of surface data and control-flow. In 
particular, setq's used to achieve data-flow are translated into data-flow links and 
COND's and other control primitives are translated into case structured segments with 
conditional-control-flow links. The plan diagram given to REASON for analysis is the 
following: 
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List-1 


List-2 


Create-Ni1 

J Current-RccumuI at I on 


Intersect 


flu I I? 


Null? 


JoIn-1 



Real ■ 
Uork 


Join-3 


Reverse 
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The specs for this routine are as follows: 

(Defspecs Fast-intersect 

( Inputs: List-1 List-2) 

(Expect: (Object-type List-1 Sorted-list) 

(Object-type List-2 Sorted-list)) 

(Outputs: List-3) 

(Assert: 

(Object-type List-3 Sorted-list) 

(For-al1 { :el) 

(And (Member list-1 :el)(Member list-2 :el)) 

(Member list-3 :e1)) 

(For-all ( :e1) 

(Member list-3 :el) 

(And (Member list-1 :el)(Member list-2 :el))))) 

These specs refer to descriptions of data objects which I have not yet presented. 
These details are developed more extensively in a later chapter. However, all the 
notions used here are intuitive. The predicate sorted-list means that the list is sorted 
in increasing order by unique-identifier (the maknum function of MacLisp). The 
quantified statements in the specs say that all elements of the intersection are in the 
output nst and that only these elements are in the output list 

Actually, the inner routine fii does all the work of the program, and is called 
recursively. This means that we have to give a specification for this inner routine. In 
the next chapter I will develop a method which will remove this need by allowing 
REASON to recognize parts of a program as instances of standard plans whose 
specifications we already know. The specs for fii are: 
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Given 
specs) 
the 
the 
disju 
exact 
since 
have 
ordeii 


(defsbecs FI1 
( Inpjits : List-1 List-2 CA) 

(Expect: (Object-type List-1 Sorted-List) 

(Object-type List-2 Sorted-List) 

(Object-type CA Reverse-Sorted-List) 

(For-al1 ( : x ) 

(Or (Member List-1 :x)(Member List-2 :x)) 
(For-al1 (:y) 

(Member CA :y) 

(< [Unique-Id :y] [Unique-Id :x])))) 

(Outputs: Final-Accum) 

(Assj rt: 

(Object-type Final-Accum Reverse-Sorted-List) 

(F Of-al1 (:x) 

(And (Member List-1 :x)(Member List-2 :x)) 

(Member Final-Accum :x)) 

(Fo|-all (:x) (Member CA :x) 

(Member Final-Accum :x)) 

(Foij-all (:x) (Member Final-Accum :x) 

(Or (and (Member List-1 :x) 

(Member List-2 :x)) 

(Member CA : x ))))) 


output 


these specs for fii, it is an immediate consequence that fast-intersect satisfies it 
fast-intersect calls fii with its two input lists as the two lists, and with nil as 
a input Since nothing is a member of nil, the second quantified statement in 
asserts of fii is vacuous; similarly the third quantified statement contains a 
jiction whose second disjunct is vacuous if the ca input is nil, the other disjunct is 
y that required by fast-intersect. Similarly, the expect clauses are met simply; 
the input ca is nil, it is a vacuous condition that all elements of list-i and list -2 
larger u id's than the elements of ca. Finally, fii produces a list in reverse sorted 
which is then reversed by fast-intersect, producing the required sorted list as 


the a 


I will now describe the actions which the symbolic interpreter takes in evaluating 
bove plan diagram. However, going through all of the details would be an overly 
cumbersome exercise, so I will try to present this without too much tedium and 
repetition. The system begins by creating an input situation and anonymous objects 
to st|ind for the inputs to the program. We will call these s- in, list-i and list-2 

respectively. The system then asserts the expect clauses of fast-intersect's specs. This 
gives us: 
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F-l ((Object-type List-1 Sorted-List) S-In) 

F-2 ((Object-type List-2 Sorted-List) S-In) 

Next the system evaluates the segment create-nil which simply asserts that its output is 
nil; REASON names the output situation of create-nil create-nil-out, thus we have: 

F-4 (Output Create-nil The-Nul1-Object Nil) 

F-5 ((Object-type Nil Empty-List) Create-Ni1-Out) 

The data objects are next moved along the data-flow links to the input ports of fu, 
the routine which actually does the work. Since there are no side-effects in this 
program, all assertions which are true in one situation will be true in all succeeding 
situations. (Side-effects change this drastically; I will discuss the problems of side- 
effects in greater detail later). Therefore the following facts are true in the input 
situation of fii which REASON names s-in-i: 


F-6 

( Input FII LI 

List-1) 

F - 7 

( Input FII L2 

List-2) 

F-8 

( Input FII CA 

Nil ) 

F-9 

((Object-type 

List-1 Sorted-List) Fll-In) 

F-10 

((Object-type 

List-1 Sorted-List) Fll-In) 

F-ll 

((Object-type 

Nil Empty-List) F11- In) 

F -12 

((Object-type 

Nil List) Fll-In) ( 


As mentioned above, REASON has the specs for fii already. So if it can show 
that the expects of fii are satisfied, it can use the asserts directly. These expects are, 
however, direct conclusions. REASON declares this invocation of fii applicable, 
create an output situation fii-out, and adds the asserts to this situation, getting: 
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F- 15 (Output FI1 Final-Accum Final-Accum-0) 

F-16 ((Object-type Final-Accum-0 Reverse-Sorted-List) F 11-Out) 

F-17 (For-all (:x) 

((Member NIL :x) FI1-IN) 

((Member Final-Accum-0 :x) F11-Out)) 

F- 18 ( For-al 1 ( :x) 

(And ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) F 11-IN)) 

((Member Final-Accum-0 :x) FI1-0UT)) 

F-19 (For-all (:x) 

((Member Final-Accum-0 :x) F 11-OUT) 

(Or (and ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) FI1-IN)) 

((Member NIL :x) F 11-IN))) 

The outputs now flow to the reverse segment whose only effect is to change the 
object type statement above, producing a sorted list instead of a reverse sorted list 
REASON can then immediately show that the desired results hold in the output 
situation of fast-intersect. 

However, to use the specs of the internal routine fii with confidence, REASON 
must demonstrate that its specs follow from its plan diagram; therefore, it creates 
anonymous inputs for fii and begins to symbolically evaluate the plan diagram for fii. 
REASON names the two lists input to fii list-i and list -2 (as above) and the current 
accumulation ca. The expect clauses of fii are asserted in the input situation of the 
curreit application of fii: 

F-20 ! ((Object-type List-1 Sorted-List) FI1-IN) 

F-21 ((Object-type List-2 Sorted-List) FI1-IN) 

F-22 i ((Object-type CA Reverse-Sorted-List) F 1 1 - IN ) 

F-23 (For-al1 (:x) 

(Or ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) FI1-IN)) 

(For-all (:y) 

((Member CA :y) FU-IN) 

((< [Unique-Id :y] [Unique-Id :x]) F11-IN))) 

Notice that situation tags have been added to the quantified statements in the spec 
clauses using the simple defaulting rule that clauses mentioning output objects are 
assigned to the output situation of the segment REASON draws a few direct 
conclusions from the above assertions: 
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F-25 ((Object-type List-1 List) FI1-IN) (type-inherit F-20) 

F - 2 6 ((Object-type List-2 List) FI1-IN) (type-inherit F-21) 

F-27 ((Object-type CA List) FI1-IN) (type-inherit F-22) 

REASON now begins the symbolic evaluation of fii. The data-flows lead to the 

two tests which must be evaluated immediately upon entrance to fii. The first of 
these segments tests whether list-i is null REASON concludes that there is no 
relevant information in the situation fii-in. It creates a case-split, assuming in one 
case that the list is null and in the other that it is non-nulL In the non-null case it 

i 

must evaluate the second test segment where a similar decision is made. REASON 
now has three conditional-control-flows waiting for further evaluation. The first of 
these represents the case where list-i is nulL The second represents the case where 
neither list-i nor list -2 is null. The final case is where list -2 is null but list-i is 
not. However, the first and the third cases both lead to join-i. Both cases of join-i 
take the same input current-accumulation. Since this input is available the join can be 
evaluated immediately. The only action following from the join join-i is a second join 
join- 3 . This join, however, cannot be evaluated yet since it has another input which 
is not available. REASON, therefore, returns to the top of the diagram considering 
the case where both lists are non-nulL This case leads to the sub-segment labeled 

real-work in the diagram. 

I 

real-work is invoked after both tests have taken the non-null branch. REASON 
brings in the assumptions of this case, making the following assertions active: 

I 

F - 30 ((Not (Object-type List-1 Empty-List)) REAL-WORK-IN) 

F -31 ((Not (Object-type List-2 Empty-List)) REAL-WORK-IN) 

There are now four segments which may be evaluated immediately*, car-i, maknum-i, 
car- 2 , and maknum- 2 . The two car segments create output objects representing the first 
objects of each list, while the two maknum segments create objects representing the 
numbers which are the unique-id's of the first elements of the two lists. This leads to 
the following assertions-* 

F-40 ((First List-1 First-1) CAR-1-0UT) ; justifications here indicate 

F-41 ((First List-2 First-2) CAR-2-0UT) ; the fact name of the correct 

F-42 ((Unique-id First-1 Number-1) MAKNUM-1-0UT) ; spec clauses from 

F-43 ((Unique-id First-2 Number-2) MAKNUM-2-0UT) ; each segment's specs. 
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I sho.ild explain that my notation in the plan diagram has been somewhat sloppy. 
car -1 and car -2 are both segments of spec-type car; it is the specs for this spec-type 
which REASON uses and similarly, for maknum-i and maknum- 2 . I should also note at 
this point that the system makes use of two properties of unique-id's which I have not 
yet stated. First, unique-id's are a one-to-one mapping, so that if the unique-id of one 
objeci is equal to the unique -io of a second object, then the two objects are identical 
Secondly, since uio's are numbers; any two uio's are either equal, or one of the two is 
greater than the other. 

Following the evaluation of the maknum segments, the only segment ready for 
evaluation is the test segment labeled *<>? which takes as inputs number-i and number- 2 , 
anonymous objects representing the uio's of the first elements of the two lists. The 
test \ as three cases, corresponding to the possibility that the two numbers are equal, 
that the first is smaller, or that the second is smaller. REASON decides that there is 
no evidence available to decide this question and, therefore, creates a case-split 
REAS ON considers the first case first getting the following justification structure: 


F -98 ! 

F -99 i 
F-100 [ 


((Not (Equal Number-1 Number-2)) =<>?-Out) ; note no 

(Select Case-1 =<>?) ; justification 

((Equal Number-1 Number-2) =?<>-0ut) (Case-split-assumption (F-99) (F-98)) 


This triggers REASON to conclude that first -1 and first -2 are identical: 


f- 


01 


(Id First-1 First-2) (One-to-One F-100) 


The :onditional-control-flow link leading from the test =<>? leads to the segment 
labeled rw-i. The data-flows take the object first-i to the cons segment as one input; 
the oject ca is the other input list- 1 and list -2 flow to the two cdr segments. The 
specs of cons say that it produces a new cons-cell whose left is the object first- 1 and 
whose right is the object bound to ca which is known to be a list Rules in the 
system which represent the definition of list membership make several inferences from 
these two assertions: 
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F-199 (Output Cons-1 The-new-cons C-l) ; justifications pointing 

F-200 ((Left C-l First-1) C0NS-1-0UT) ; to the spec clauses 

F-201 ((Right C-l Ca) CONS-l-OUT) ; would go here - they are 

F-202 ((Object-type C-l Cons-cell) CONS-l-OUT) ; omitted for simplicity 

F - 20 3 ((Object-type C-l List) CONS-l-OUT) (list-rep f-202 f-201 f-200 f-24) 

F - 204 ((First C-l First-1) CONS-l-OUT) (list-rep f-203 f-200) 

F -205 ((Rest C-l Ca) CONS-l-OUT) (list-rep f-203 f-201) 

F -206 ((Member C-l First-1) CONS-l-OUT) (list-mem f-203 f-204) 

F - 20 7 (For-all (:x) (list-mem f-203 f-205) 

((Member Ca :x) CONS-1-1N) 

((Member C-l :x) CONS-l-OUT)) 

The origin of the rules which make such inferences will be explained in more detail in 
the chapter on describing data objects. 

The two cor segments produce the obvious output assertions: 

F-207 ((Rest List-1 Rest-1) CDR-l-OUT) 

F-208 ((Rest List-2 Rest-2) COR-l-OUT) 

These objects now flow to the recursive call to fii. So far I have not mentioned any 
checking of input expectations since these have all been trivial, fii, however, requires 
that its two input lists be sorted, and that its accumulation input be sorted in reverse 
order. These first two requirements are met simply; since rest-i and rest -2 are the 
cdr's of sorted lists, they themselves are sorted. The condition that c-i be sorted in 
reverse order is also met quite simply. Its cdr ca is a reverse-sorted list and input 
expectations stated that first -1 has a larger maknum than any member of ca. Thus, fii 
is applicable and its output assertions can be added to the data base. This creates a 
new output final-accum-i and three quantified statements: 
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F -209 
F -210 


F -211 


F -212 


((Object-type Final-Accum-1 Reverse-Sorted-List) FIl-1-Out) 
(For-all ( : x) 

((Member C-l :x) FI1-1-IN) 

((Member Final-Accum-1 :x) F 11 -1-Out)) 

(For-all ( : x ) 

(And ((Member Rest-1 :x) FI1-1-IN) 

((Member Rest-2 :x) FI1-1-IN)) 

((Member Final-Accum-1 :x) F11 -1-OUT)> 

(For-all (:x) 

((Member Final-Accum-1 :x) F 11-1-OUT) 

(Or (And ((Member Rest-1 :x) F 11-1-IN) 

((Member Rest-2 :x) F11-1-IN)) 

((Member C-l :x) FI1-1-IN))) 


This output now flows to the join join-3 which has other unavailable inputs. 
REASON, therefore, returns to the next case of the test =<>?. In this case, it assumes 
the negation of the improvable clause from case-i and then attempts to prove that the 
when clause of case -2 holds. Thus, REASON assumes that the uid's of the two objects 
first- i and first -2 are distinct Since the uio is a one-to-one property this indicates 
that i irst -1 and first -2 are distinct Furthermore, since the uio is a number and since 
REASON knows that these two numbers are distinct, it asserts that one of the 
numbers must be larger than the other. The following assertions result 


F -299 
F -98 
F-301 
F -302 


Select Case-2 =<>?) 

(Not (Equal Number-1 Number-2)) =<>?-IN) 
Not (Id First-1 First-2)) 

Or ((< Number-1 Number-2) =<>?-IN) 

((< Number-2 Number-1) =<>?-IN)) 


(Case-split-assumption (F-299) (F-99)) 
(UID-Not-* F-98 F-42 F-43) 

(NumProp F-98) 


REASON now attempts to prove the when clause of case- 2 , however, this too can be 
seen |o be unprovable. It then sets up the next stage of the case-split 

F-303 (Select Case-3 =<>?) 

F-304 ((Not (< Number-1 Number-2)) =<>?-IN) (Case-Split-Assumption (F-303) (F-99 F-299)) 

F-305 ((< Number-1 Number-2) =<>?-IN) (Case-Split-Assumption (F-299)(F-304 F-99)) 

F-98 ( Not (Equal Number-1 Number-2)) =<>?-IN) (Case-split-assumption (F-303)(F-99 F-299)) 
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Notice that the justifications are so set up that ( 1 ) if either case-2 or case -3 is selected 
the assertion f- 98 will be m; (2) if case -2 is selected F -305 will be in, unless there is 
some reason found to believe its negation; (3) If case -3 is selected F -304 and f-98 will be 
in. 

The assertion F-305 makes case-2 applicable. REASON asserts that case-2 is 
applicable and since there are no output assertions to add, it follows the conditional- 
control-flow link from case-2 to the segment rw-2 which takes the cdr of its input 
list-1 and then calls fi 1 recursively. Notice that the pre-requisite conditions of fii are 
met trivially in this case. The cdr of list-i must be a sorted list as noted earlier; the 
second input is list-2 which is known to be sorted; finally, the current-accumuland input 
is ca which was known to be sorted in reverse order. Thus, fii is applicable within 
this sub-plan as welL The output assertions of this application of fii which REASON 
names f 11-2 are similar to those above: 

((Object-type Final-Accum-2 Reverse-Sorted-List) FI2-l-0ut) 

(For-al1 ( : x ) 

((Member CA :x) F 11-1-IN) 

((Member Final-Accum-2 :x) FII-1-Out)) 

(For -al1 ( :x) 

(And ((Member Rest-1 :x) F12-2-IN) 

((Member List-2 :x) F 12-2-IN)) 

((Member Final-Accum-2 :x) FI2-2-OUT)) 

(For-al1 (:x) 

((Member Final-Accum-2 :x) FI2-2-OUT) 

(Or (and ((Member Rest-1 :x) F12-2-IN) 

((Member List-2 :x) F12-2- IN) ) 

((Member CA :x) F12-2-IN))) 

The justification of these assertions which I have omitted for brevity points back 
to the relevant spec clause, output object, and applicability assertions. The output of 
this segment leads to the join join-2 which is waiting for another case's input 
REASON now turns to the final case of =<>?. As shown above, REASON assumes in 
this case that it is false that number -1 is smaller than number-2. It then concludes by 
disjunction elimination that number-2 is smaller than number-i: 

F-314 ((< Number-1 Number-2) <?-0UT) (Disj-El im F-304 F-302) 


F - 310 
F-311 


F -312 


F -313 
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Actually, I have been taking a slight liberty in the justifications I have shown since as 
each| assertion is moved along a flow link, a new assertion is created with a new 
situation tag. I have used the fact name of the original assertion in these 
justifications as a notational convenience. 

n any event f-314 is all that is needed to conclude that the third case of the test 
is applicable. Control therefore flows to rw 3 which produces assertions similar to those 
of r^;. The control-flow link from rw3 to join -2 is now active. 

>oin -2 produces a single output object which is the join of the output produced 
by r> 1 , rw 2 , and rw 3. These are the final accumulations produced by the internal 
recursive calls to fii. REASON names this output of join -2 fa. This output then 
flowfe to join-3 where it is joined with the output of join-i. Examination of the 
diagbim shows that the output of join- 1 is current-acc, the input to the outer fii, since 
current-acc flows to both cases of the join. Thus, the two inputs to join -3 are fa and 
current-acc; REASON names the output of this join FINAL-ACCUM-Q. The plan 
diagram specifies that this is the output of the main segment fii. Symbolic 

intepf retation is, therefore, complete and REASON now tries to prove the asserts of 
the ti|iain segment. 

There are three things to be proved: (1) All elements of the intersection are 
accumulated (2) Nothing is lost from the current-accumulation input (3) Nothing 
extraneous is accumulated. I will show the proof of first of these claims. This is 
statec formally as follows: 

I 

(For-all (:x) 

(And ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) FI1-IN)) 

((Member Final-Accum-0 :x) FII-OUT)) 

To begin the proof of this statement REASON creates an anonymous object to stand 
for the variable of the quantified statement and then assumes the antecedent clause 
with this anonymous object substituted for the variable. 

F-1000 (And ((Member List-1 0bj-l) FI1-IN) 

((Member List-2 Obj-2) F 11-IN)) 


For Complex Program Understanding 






132 An Example of Symbolic Interpretation 

REASON also establishes the sub-goal for the quantified statement: 

F-90 (Goal ((Member Final-Accum-0 Obj-1) FI1-0UT) (Achieve-goal ...)) 

for ((For-al1 ( :x) 

(And ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) F11-IN)) 

((Member Final-Accum-0 :x) FI1-OUT)) 
in ((And ((Member List-1 Obj-1) FI1-IN) 

((Member List-2 Obj-2) F11-IN)))) 

The antecedent of the quantified statement is then expanded, yielding the two 
conjuncts: 

F-1001 ((Member List-1 Obj-1) FI1-IN) 

F-1002 ((Member List-2 Obj-2) FI1-IN) 

however, rules relating to list structure conclude from these that both lists are not 
empty. 

F-1003 ((Not (Object-type List-1 Empty-List) FI1-1N)) (List-def F-1001) 

F-1004 ((Not (Object-type List-2 Empty-List) FI1-IN)) (List-def F-1002) 

This brings in the applicable assertions for the non-null cases of the two null? tests, 
which in turn causes the conditional-control-flow link from the null? test to real -work 
to be declared active. This in turn brings in the assertion saying that case-i of join -3 
is applicable; the output of join-3 is therefore now declared to be id to the output of 
real-work which is fa. This triggers the identification mechanisms to create a new 
subgoal in which final-accum-0 is replaced by fa. 

F-91 (Goal ((Member FA Obj-1) FI1-0UT) 
for ((For-all (:x) 

(And ((Member List-1 :x) FI1-IN) 

((Member List-2 :x) F11-IN)) 

((Member FA :x) F11-OUT)) (Achieve-goal 1)) 
in ((And ((Member List-1 Obj-1) FI1-IN) 

((Member List-2 Obj-2) FI1-IN)))) 

The data-base is now quiescent REASON next expands the antecedents of the 
quantified statement 
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F -1005|| (Or ((First List-1 Obj-1) F 11 - IN) (F-1001 List-Mem-def inition) 

((Member [Rest List-1] Obj-1) FI1-IN)) 

F -1006|| (Or ((First List-2 Obj-1) FII-IN) (F-1002 List-Mem-def inition) 

((Member [Rest List-2] Obj-1) F 11-IN)) 

The reference expressions in both expressions can be resolved since F -207 and F -208 
state what the rest of each list is. Notice that although these facts are tagged with 
situation tag cor-i-out, there are no side-effects in this program and all assertions 
except those involving newly created objects may be moved back through any segment 
to the beginning of the program (REASON has a different fact name for the same 
facts in the initial situation, however, for simplicity of presentation I am ignoring this 
detail. We obtain: 

F-1007 1 ] (Or ((First List-1 Obj-1) FI1-IN) (Reference-Resolution F-1005 F-207) 

((Member Rest-1 Obj-1) FI1-IN)) 

F-10081 (Or ((First List-2 Obj-1) FI1-IN) (Reference-Resolution F-1006 F-208) 

((Member Rest-2 Obj-1) F 11-IN)) 

Ther4 are now several strategies which REASON might pursue. It could attempt a 
proof by cases, splitting either of the above disjunctions (F -1007 or F- 1008 ) or the 
disjunction of select statements associated with either the test -<>? or the join join- 2 . 
The current version of REASON, has a preference for splitting disjunctions arising 
from the goal, rather than case-split or join oriented disjunctions. REASON attempts 
to show the goal F -91 by splitting F- 1007 . It first assumes: 


F -1009 


Howe 


FIrst- 

F -1010 
F-1011| 

Now 


a. 


For 


((First List-1 Obj-1) FI1-IN) (Case-split-assumption F-1007 ... ) 


ver, the system has already asserted F -40 which states that the first of List-i is 
Thus, an identification is made, leading to the following: 


(Id First-1 Obj-1) (Parts-Id F-1009 F-40) 

((Unique-Id Obj-1 Number-1) Maknum-l-Out) (Identification F-1010 F-42) 

the system chooses to case-split the second disjunction F- 1008 . It obtains 
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F-1012 ((First List-2 Obj-1) FI1-IN) (Case-split-assumption F-1008 ...) 

F-1013 (Id First-2 Obj-1) (Parts-Id F-1012 F-41) 

F - 10 14 ((Umque-Id Obj-1 Number-2) Maknum-l-Out) (Identification F-1013 F-44) 

This, in turn creates another identification: 

F-1015 (Id Number-1 Number-2) (Func-Prop-Id F-1011 F-1014) 

However, F -1015 means that case-i of the test •<>? is applicable. Thus, the assertions 
pertaining to rv-i come in since this is the segment which follows from c«sa-L 
Further identification follows: 

F-1016 ((Member C-l Obj-1) C0NS-1-0UT) (Identification F-206 F-1018) 

This last assertion interacts with the quantified statement F -211 to create the new 
assertion: 

F-1017 ((Member Final-Accum-1 Obj-1) FIl-1-Out) (For-All F-211 F-1016) 

Finally, since the control-flow coming into case-i of join -2 is active, the assertion 
stating the applicability of this case comes in. This, in turn, brings in an id assertion 
stating that final-accum-i is identical to the output of join -2 which is fa. This triggers 
another round of identifications: 

F-1018 (Id Final-Accum-1 FA) (Join-Select ...) 

F-1019 ((Member FA Obj-1) FI1-1-0UT) (Identification F-1017 F-1018) 

This assertion then passes directly through join -2 and join-3 satisfying the desired goal. 
However, this was only the first case of the second case-split REASON now revokes 
the assumption F -1012 and makes the assumption that obj-i is a member of rest-2 , the 

CDR Of L ist - 2. 

F-1020 ((Member Rest-2 Obj-1) FI1-IN) (Case-split-assumption F-1008 ...) 

Notice that all the identifications triggered by the assumption F -1012 are now owf, since 
that assumption has been outt d by the proof-by-cases mechanism. However, 
REASON still has the assertion that obj-i is identical to first -1 since it has not yet 
revoked that assumption. Rules relating to list structure trigger, this time concluding 
that the unique-id of obj-i is greater than that of first -2 since it is a member of the 
cdr of a sorted list of which first -2 is the car. 
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F -102]) | ((> [Unique- Id Obj-1] [Unique-Id First-2]) FI1-IN) (Lists F -1020 F-208 F-41 F-20) 

The reference expressions in the above assertion need to be resolved and both 
referents are available. We get 


F-1022 ((> Number-1 Number-2) FI1-IN) (Ref-Resolution F-1021 F-1011 F-43) 

Rules reflecting knowledge about numbers and the one-to-one character of the uio 
trigger: 


now 

F-102$ 
F -1024 
F-102$ 


F -102(| 


((Not (< Number-1 Number-2)) FI1-IN) (Num-Prop F-1022) 

((Not (Equal Number-2 Number-1)) FI1-IN) (Num-Prop F-1022) 

(Not (Id First-2 Obj-1)) (UID-Prop F-1024 F-1011 F-43) 


Assertions f -1025 and F- 1023 , however, imply that case-i and case -2 of the test «<>? are 
inapplicable and F -1023 implies that case-3 of the test is applicable. Therefore, rw 3 is 
the segment to which control is transferred However, during the symbolic evaluation 
of RV3, a quantified statement was created which stated that any object which was 
both a member of list-i and rest-2 is a member of final-accum-3, the output of the 
internal call to fii. We obtain: 


((Member Final-Accum-1 Obj-1) RW3-0UT) (For-All F-1020 F-1009 ...) 


As above, this passes through the joins directly and the desired goal is achieved in this 


case. 


Thus, REASON has finished proving that if the object obj-i is the first object 
of ii|t-i it will be a member of the final output REASON now considers the other 
case of the disjunction f -100 7 , It assumes: 


F -1027 


1 $ 


F-102«# 

first 

of L 

The 
with! 
only 

OBJ -1 


((Member Rest-1 Obj-1) Fll-IN) (Case-Split-Assumption F-1007 ...) 


whicn triggers a set of deductions similar to those which followed from the assumption 
REASON again decides to try proof by cases on the disjunction F-1008. The 
^ase of this proof brings back in the assumption F-1012 which states that the first 
t -2 is obj-i. This selects case -2 of the test =0? and rules out the others as above, 
quantified statement produced by symbolic evaluation of the internal call to fii 
p rw 2 is triggered just as above, leading to the desired conclusion. This leaves 
one final case to consider. REASON brings in the assumption F-1020, stating that 
is a member of the cdr of list- 2 . 


For Complex Program Understanding 



136 


An Example of Symbolic Interpretation 


REASON now has the following four facts m 

F-1001 ((Member List-1 Obj-1) FI1-IN) 

F- 100 2 ((Member List-2 Obj-2) FI1-IN) 

F-1020 ((Member Rest-2 Obj-1) FI1-IN) 

F- 1027 ((Member Rest-1 Obj-1) F 11-IN) 

The desired goal has not yet been obtained, so REASON finally resorts to splitting 
the disjunction associated with join- 2 . First it assumes that case-i of the join is 
selected, ini ng the assumption that case-i of the test =<>? is selected. Thus rwi is 
active. However, associated with its internal call to fii is a statement that any 
member of both rest-i and rest -2 will be a member of the output This will satisfy 
the sub-goal as we've seen above. Selecting case -2 of join -2 will take control to rw2 
which says that any object which is in rest-i and list -2 will be a member of the 

output. Finally, Selecting case -3 will lead to rw 3 and the requirement that the object 

be in list-i and rest- 2 . Since obj -2 satisfies all of these requirements it is a member 

of the output of JOIN-2 in all cases. Thus, the proof is complete. 

The proofs of the other goals follow along similar lines, involving no mechanisms 
other than those shown so far. The proof shown above was constructed by the first 
implementation of REASON, although some technical details were different In the 
next two chapters I will turn to the issues of categorizing standard plan fragments 
which motivated the new implementation effort 
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Chapter 8: The Temporal Viewpoint 

The problem with the proof given in the last chapter is that it involved a lot of 
harcj work proving things which most programmers would recognize as examples of 
things they already know. This puts a premium on the recognition of pre-proven 
"plap fragments". Most previous research on the use of pre-proven schemata such as 
that| of [Gerhart, 1975] has relied on syntactic templates and correctness preserving 
transformations on the program syntax. In contrast, the Programmer's Apprentice 
represent its knowledge of standard programming techniques in the plan formalism, 
using data-flow and control-flow links to abstract away from the syntax of the 
prog lamming language. In addition, we use symbolic evaluation and a situational logic 
to tp k about the internal states of the computation. 

Two distinct segmentations of a program can be made, each revealing different 
aspects of its teleological structure. The first is a segmentation of the surface 
features, called the surface viewpoint which abstracts out the communication 
primitives of the programming language; the second expands the program into a 
sequence of situations which are regrouped into the temporal viewpoint. This technique 
allows programs to be described and catalogued in a high-level vocabulary which is 
suitable for use as a very-high-level programming language or as a command language 
to aj programmer's apprentice system. 

Section 8.1: A Paradigmatic Example 

Consider the following LISP routine which traverses a tree and builds a list of its 
leaf nodes (i. e. it is a fringe program): 

(define fringe (tree)(fringe-1 tree nil)) 

(define fringe-1 (current-node accumulation) 

(cond 

((test-leaf current-node)(cons current-node accumulation)) 

(t (fringe-1 (left current-node) 

(fringe-1 (right current-node) 
accumulation))))) 
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FRINGE 


The program might be paraphrased as follows: If the current-node is a leaf node 
then cons it onto accumulation, the current list of leaf nodes; if it is not then add to 
accumulation all those leaf nodes which are daughters of the right node of the current- 
node. Then add to the result of that computation all those leaf nodes which are 
daughters of the left node of the current-node. If started with the tree as the current- 

node and nil as the accumulation, the program will build a list containing exactly the 
leaf nodes of tree. 
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A standard proof of correctness of the above program would closely follow the 
description, using induction to argue that the right recursive call accumulates all 
leaf nodes of the right branch and then that the left recursive call accumulates 
cj'thers. However, such a proof does not make use of knowledge which is second 
to most LISP programmers. The fringe program follows a standard pattern of 
e recursion on the branching structure of the tree. In this case the standard 
ecursion is augmented by the presence of (1) A cons and (2) A second argument 
function definition of fringe- i; the purpose of this argument is to accumulate 
of leaf nodes. Were we to ignore these extra features, we would be left with 
(gram which does nothing but traverse a tree. 


the 

set 


(define traverse-a-tree (tree) 

(cond ((test-leaf tree)) 

(t (traverse-a-tree (left tree)) 

(traverse-a-tree (right tree))))) 

Although the logic underlying this code is a cliche of LISP programming, it is 
not if ossible to specify this segment's behavior using standard input/output descriptions. 
Indeed, traverse-a-tree produces no outputs at all, and thus, has no I/O behavior to 
specify. However, the segment does have useful temporal behavior during its 
commutation it visits every node of the input tree. Secondly, during its computation 
TRAVEifijsE-A-TREE filters the nodes of the tree into leaf nodes and non-leaf nodes, creating 
k of control states in which precisely the leaf nodes are available. Thus, the I/O 
ptions of Hoare [Hoare, 1969] logic are inadequate for this purposes and a logic 
of greater strength is needed. Those interested in the logic of computer programming 
are now studying such logics [Pnueli, 1977] [Pratt, 1978] although with other purposes 


For Complex Program Understanding 





140 


The Temporal Viewpoint 


in mind. 

If we ignore the tree-traversal part of fringe, focusing our attention on the rest of 
the code's behavior, we can give an equally simple characterization of the temporal 
behavior of this fragment of the code. Having noted that tree-traversal produces a set 
of control states in which the program visits the leaf nodes, we may then further 
observe that the rest of the program acts in these control states. In each such state 
there is a cons operation which adds the current leaf node onto the current 
accumulation. This new accumulation is then passed on to either the next occurrence 
of a control state in which a leaf node is visited, or if there are no further leaf nodes 
the accumulation is passed out of the program as the answer. This process of 
sequentially accumulating additional values is also a cliche 1 of LISP programming which 
I will refer to as sequential-cons-accumulation 

This leads to a different view of the fringe program. We may now regard it as a 
"composition" (in the sense of functional composition) of a tree-traversal, a leaf-filter, 
and a sequential-cons-accumulation. In contrast to normal compositions which 
communicate by passing a set of data-objects each of which exists as a unified object 
at the time of the functional invocation, this composition instead passes temporal 
collections of values which can be regarded as a unified object only by abstracting 
away from the program's sequential behavior. This view of a recursive program as 
being composed of a generator together with a consumer is used in the languages CLU 
[Liskov et at, 1977] and ALPHARD [Wulf et aL, 1976] and is the basis of both the 
language APL [Iverson, 1962] and the loop analyzer used in the programmer's 
apprentice project [Waters, 1978]. 

It would be desirable to be able to construct the following (more natural) proof 
of the fringe program: First, we already know that tree-traversal visits every node of 
the tree and that it filters out all but the leaf nodes. Second, each such node is 
passed to sequential-cons-accumulation. Third, we already know that sequential-cons- 
accumulation will return a list of exactly those objects which it was passed as inputs. 
Finally, since the output of sequential-cons-accumulation is the output of fringe, it follows 
that the fringe program produces a list of exactly the leaf nodes of its input tree. 
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Temporal View of Fringe Program 
Tree Traversal and Sequential-Cons-Accumulation 

The advantage of this method is that we can make use of previously constructed 
of the properties of tree-traversal and sequential-cons-accumulation; however, in 
to reap this advantage we will have to construct rules of inference which allow 
prove temporal properties of program segments and which tell us when it is 
ble to apply these properties. 
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In previous chapters a formalism was developed for describing programs while 
abstracting away from the primitives of the programming language, using instead the 
notions of segmentation, data, and control-flow. I have also presented a symbolic 
interpreter for these descriptions. In designing this symbolic interpreter I was careful 
to represent explicitly many items which had only implicit representation in my earlier 
system [Rich & Shrobe, 1976]. This more explicit representation was created so that I 
could easily define and discuss program properties other than simple I/O behavior and 
so that program fragments which are characterized by their temporal behavior can be 
catalogued. 

The symbolic interpreter used in REASON defines the basic notions needed to 
build temporal descriptions by connecting segments, situations, and objects into 
applications (an application is a segment together with its input and output mappings, 
as well as its input and output situations). As the interpreter goes through its 
symbolic evaluation of a plan diagram it records the applications which it encountered 
in that process. Since we are interested in the temporal properties of a segment, one 
of our main goals will be to discover exactly what applications occur within a 
particular segment's execution; knowing this, we will be able to group these 
applications into the temporal viewpoint segmentation. However I must first make a 
few additional observations about the nesting and grouping of applications. 

Intuitively, the application a of segment- 1 occurs during the application b of 

segment-2 if while interpreting b the interpreter will encounter an input situation in 
which it applies segment- 1 to some set of inputs, segment- 1 together with the set of 
inputs, the set of outputs, the mappings of these to the input and output names of 
segment- i, and the input and output situations constitute the application a. 

More formally, we say that an application A of segment-1 occurs within an 

application B of segment-2 if the following conditions hold: 

(a) The segment of application a is segment-i and the segment of application b is 

SEGMENT-2. 

(b) segment-1 is a sub-segment of segment-2. 

(c) Each data-flow link terminating at segment-i originates either at an input of 

segment-2 or at an output of some other application c where c occurs within b. 

(d) Each data-flow link originating at segment-i terminates at either an output of 

segment- 2 or at an input of some other application c where c occurs within b. 

(e) Each conditional-control-flow link which terminates at a originates at an 
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app|i ration c which occurs within b. Furthermore, the conditional-control-flow link 
originates at an applicable case of the segment of c. 

The relationship is transitive, so that if a is an application within b and b is an 
appji ration within c, then a is an application within c as welL We express this as 
folio 


(application-within A B) 

whic.i states that a is an application within b. 

Frequently it is more useful to talk about applications of segments of a particular 
(plan or spec) type rather than applications of a particular segment We use the 
following notation to express this idea: 

( appl icat-ion-of-type <plan-type> Application)) 

The above can be defined by the following equivalence: 

( application-of-type type-1 appl-1) 

(plan-type [segment-part appl-1] type-1) 

We roted earlier that in the tree-traversal plan there is an application of a segment of 
type tree-traversal for every node of the tree However, some of these applications 
occiii within the sub-segment called on the left branch while others involve the right 
In this case, we are concerned not only with applications of the particular surface sub¬ 
segments, but also with applications of all segments of type tree traversal 

We say that there is an occurrence of plan-type type-1 within the application A of 
segmmt-1 if: 

(i) I here is an application b of segment seg-i within the application a 

(ii) The plan-type of seg-i is type-i. 

We express this as follows: 
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(occurrence-within <app1 ication-A> <plan-type> <application-B>) 

the following equivalence holds: 


(occurrence-within appl-1 type-1 appl-2) 

(and ( application-within appl-1 appl-2) 

(application-of-type type-1 appl-2)) 

We can now state a formal property of the tree-traversal fragment which will be 
useful throughout the rest of this discussion, namely that it visits every node: 

(For-all (:appl-1) (application-of-type tree-traversal :appl-1) 

(For-al1 (:node) (node [input appl-1 the-tree] :node) 

(There-is (:appl-2) (occurrence-within appl-1 tree-traversal :appl-2) 
such-that (input :appl-2 the-tree mode)))) 

It is convenient to think of sets of applications actually being aggregated into a 
segment This is done using the notion of an occurrence set. The occurrence set of 
plan-type type-1 within the application A is the set of all applications within A whose 
plan-type is type-1. Intuitively, the occurrence set of plan-type type-1 is a virtual 
segment consisting of that part of the program's temporal history which includes 
applications of a particular type. In an fringe program, for example, the occurrence 
set of type fringe is essentially the tree traversal fragment of the program, consisting 
of all the recursive calls to fringe. 


Section 8.2: Situations and Orderings 

Several rules are used to impose a partial order (representing temporal ordering) 
on the situations occurring in a plan diagram. Most obvious are those imposed by the 
relationship of the situations to the segments of the plan-diagram. The following rules 
capture the constraints that (1) The input situation of a segment precedes its output 
situation, (2) The input situation of a main segment precedes the input situation of 
any of its sub-segments, (3) The output situation of any sub-segment precedes the 
output situation of its main segment 
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(Rule ((:f (Is-a .segment Segment)) 

(:g (Input-situation :segment :in-sit)) 

( :h (Output-situation :segment :out-sit))) 
(Assert (Comes-before :in-sit :out-sit) 

(Seg-s 1 1-order :f :g :h))) 


(Rule ((:f (Sub-segment :mam-seg :sub-seg)) 

(:gl (Input-situation :main-seg :in-sit-1)) 
(:g2 (Input-situation :sub-seg :in-sit-2)) 
(:hl (Output-situation :main-seg :out-sit-l)) 
(:h2 (Output-situation :sub-seg :out-sit-2))) 
(Assert (Comes-before : in-sit-1 :in-sit-2) 

(Nested-seg-order :f :gl :g2)) 

(Assert (Comes-before :out-sit-2 :out-sit-l) 

(Nested-seg-order :f :h1 :h2))) 


situa 


outpjit situation of the first segment must precede the input situation of the other. 


Data-flow and control-flow links are the only other constraint ordering the 
ions. If there is a data- or control-flow link between two situations then the 


(Rule ((:f (Dataflow :seg-l :seg-2)) 

(:g (Output-situation :seg-l :out-sit)) 
(:h (Input-situation :seg-2 :in-$it))) 
(Assert (Comes-before :out-sit :in-sit) 
(dflow-order :f :g :h))) 


(Rule ((:f (Controlflow :seg-l :seg-2)) 

( :g (Output-situation :seg-l :out-sit)) 
(:h (Input-situation :seg- 2 : in-sit))) 
(Assert (Comes-before :out-sit :in-sit) 
(dflow-order :f :g :h))) 


(Rule (( : f (Conditional-Control-flow (: seg-1 :case-l) : seg-2)) 
( :g (Output-situation :seg-l :out-sit)) 

(:h (Input-situation :seg- 2 : in-sit))) 

(Assert (Comes-before :out-sit :in-sit) 

(dflow-order :f :g :h))) 


For 
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Since these constraints in general only impose a partial ordering on the situations, plan 
diagrams may be thought of as representing a (pseudo) parallel computation which 
imposes only the minimal constraints on segment ordering necessary to achieve the 
goals of the segment specified by the plan-diagram. 

Finally we may define a notion of a situation belonging to a particular 
application a, namely that it is an input or output situation of some application 
occurring within a: 


( s i tuation-of-application A sit) 

(There-is (:b) (application-within A :b) 

such-that (or (input-situation :b sit) 

(output-situation :b sit))) 


Section 8.3: Temporal Collections 

I would like to define the idea of a collection of objects distributed in time, 
rather than gathered together in a data-structure. The motivation of this, as 
mentioned earlier, is to be able to describe what a program fragment like tree-traversal 
does. I will show that tree-traversal may be regarded as producing such a temporal 
collection whose members are exactly the nodes of the input tree. 

A temporal collection is a set of pairs of objects and situations such that each 
object exists in the situation with which it is paired We may talk about elements of 
the collection and their object and situation parts as follows; 


(Element <temporal-col 1ection) <element>) 

(Object-part <element> <object>) 

(Situation-part <element> <situation>) 

Since the second two of the predicates are functions, they made be referred to with 
the bracket notation. 
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C is a temporal collection of the application A if: 

(i) e is a temporal collection 

(ii) Every element of c has a situation part which is a situation of application a. 

It is easy to create temporal collections by picking applications of sub-segments 
withi i some main segment For each such sub-segment we can chose an (input) 
outpji t object and pair it with the (input) output situation. However, it is usually 
more useful to consider an occurrence set of a particular type and to construct the set 
formed by those objects which are assigned to a particular input (output) port of each 
occiiirence. These objects are then paired with the input (output) situations of each 
occurrence to form a temporal collection. 

For example, we may consider the occurrence set of type tree-traversal within any 
application of tree-traversal. For each such occurrence, chose the input which is 
assigned to tree-traversal's input port the-tree. Pair each such object with the input 
situaiion of the occurrence to which it is an input This temporal collection contains 
exactly the nodes of the tree input to the outermost application of tree-traversal. 

From now on I will use the term temporal collection only to refer to temporal 
colle t tions generated by the <name> input (output) of the occurrence set of <plan-type> 
withi i the application a. It is denoted as follows: 

(Temp t ral-Col 1ection A The-Tree Tree-Traversal c) 

(Temp<ral-Collection Application) <input-name> <plan-type> <collection-name)) 

which says that c is the temporal collection generated by the-tree input port of the 
occurrence set of type tree-traversal. 

So far I have talked about a temporal collection as a set of pairs of objects and 
situaiions. Such pairs are said to be elements of the temporal collectioa However, 
the i iterest is usually not with the pairs but only with the object parts of the pairs. 
An object is a member of a temporal collection if there is an element of the temporal 
collection whose object part is the object in question. Notice that under the element 
relationship the temporal collection is a set; we are only interested in the presence of 
a pair in the collection, not the number of occurrences. However, under the 
membership relationship, the temporal collection is a multi-set, with objects occurring 
more than once. 
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As with other data-structures, it is frequently important to have an ordering 
relationship on the objects in a temporal collection. The temporal ordering of the 
situations provides a natural method for defining such an ordering. We say that 
dement-1 precedes element-2 in the temporal collection C if: 

(i) There is an element of c whose object part is element-i and whose situation part is 

SITUATION-1. 

(ii) There is an element of c whose object part is element -2 and whose situation part is 

SITUATION-2. 

(iii) situation -1 comes-before situation- 2 . 

Notice that since situations are only partially ordered, the elements of a temporal 
collection are in general only partially ordered. If the ordering of the elements of a 
temporal collection is total, then we say that the collection is a temporal sequence. 


Section 8.4: Temporal Collections Inputs and Outputs 

We now extend the specification language to allow temporal collections to serve 
as segment inputs and outputs. Thus, the specs for tree-traversal may now be stated 
as follows: 


(defspecs tree-traversal 

(Inputs : the-tree) 

(Expect: (Object-type the-tree Binary-tree)) 

(Outputs: the-nodes) 

(Assert: (Object-type the-nodes temporal-collection) 

(For-all (:the-node) (node the-tree :the-node) 

(member the-nodes :the-node)) 

(For-all (:the-node) (member the-nodes :the-node) 

(node the-tree :the-node)))) 

Which states that tree-traversal produces a temporal collection output whose elements 
are exactly the nodes of the input tree. We can now state the plan diagram 
assertions which link the temporal collection generated by the occurrence set of tree- 
traversal to the output the-nodes. 
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(defplan tree-traversal 

(sub-segments: test-leaf process-non-terminal 
process-terminal) 

( f1ow-diagram: 


(dataflow 

(temporal-collection the-tree leaf? tree-traversal) 
(output tree-traversal the-nodes)) 


) 

(constraints : 

(spec-type test-leaf leaf?) 
(plan-diagram process-non-terminal) 
... )) 


witlj 

assu 


It is now possible to prove that the plan diagram for tree-traversal is consistent 
its specs. In doing so REASON uses a form of computational induction. 


rbing that a temporal property holds of all occurrences of a particular plan type 

ih tn^in Tf fVio k one a f onn.__ - 


within the main application. If on the basis of this assumption it can deduce that the 


same 


property is true for any application of that plan-type. (This is actually only weak 


corre 


of computational induction plan-type computational induction 


ctness in the Hoare sense since this does not prove termination). I call this form 


property holds for the main application, then it is legitimate to conclude that the 
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To begin the proof REASON assumes that there is an arbitrary application tree- 
traversal -i of a segment of plan-type tree-traversal. Anonymous objects are chosen to 
stand for the input situation of the application. Anonymous objects are also chosen 
to stand for the inputs to the application 

(appl ication-of-type tree-traversal tree-traversal-1) 

(input tree-traversal-1 the-tree tree-1) 

(input-situation tree-traversal-1 sit-1) 

Also the input expectations of the tree-traversal specs are asserted in the input 
situation of the application 


((Binary-tree tree-1) sit-1) 
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in th 


set of test-leaf. This is trivially true since the only node of a terminal node is itself, 
and he only occurrence of test-leaf had tree- 1 as its input Thus, the plan is valid 
undei the assumption that tree-i is a terminal. 


TERMl| 

the 
the 
repr£ 
left 


The data-flow links in the plan diagram show that test-leaf is ready for applicatioa 
REA iON decides that it is impossible to prove either that tree-i is a terminal or that 
it is 
terrr 
contr! 


not. Thus, a case-split is created, assuming in the first case that tree-i is a 
inal. The plan diagram indicates that no other segments are applicable and that 
:>! flows to the main segment's output The system must prove that the main 


segment's assert clauses hold for the delivered output objects. 


There is only assert clause and it states that every node of tree-i must be present 
e output the-nodes which is the temporal collection generated by the occurrence 


f tree-i is non-terminal then case -2 of test-leaf is applicable and process-non- 
al is ready for application. REASON moves through the plan diagram evaluating 
ib-segments in turn. Since REASON has assumed that tree-i is non-terminal, 
segments left and right are applicable; objects left-i and right-i are created to 
sent their outputs and assertions are added to represent the fact that left-i is the 
node of tree-i and that right- 1 is the right node. 


Dati 

appl 

and 



(output the-1eft-node left left-1) 

(output the-nght-node right right-1) 

(left-node tree-1 left-1) 

(right-node tree-1 right-1) 

flow links then map these objects to left-traversal and right-traversal which are 
cable since they only require their input to be a binary-tree node. Both left-i 
ight-i are binary-tree nodes since they are nodes of the binary tree tree-i. 

REASON next attempts to show that the temporal collection generated by the 
’ence set of type leaf? includes exactly the nodes of tree-i. The proof is by 
type) computational inductioa REASON assumes that any occurrence o-i of 
ype tree-traversal within the main application satisfies the property which it 
wishbt to prove, i. e. that the temporal collection generated by the occurrences of type 


LEAF? 


within o-i has exactly the nodes of the input tree as its members. Thus, the 
occurences of leaf? within left-traversal and right-traversal each generate a temporal 
collection including exactly the nodes of left-i and right-i. 
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Consider an arbitrary node node-i of tree-i. By definition nooe-i is either tree-i 
itself or a node of the left node of tree-i or a node of the right node of tree-i. If 
nooe-i is identical to tree-i then it is the input to test-leaf which is of type leaf?. If 
nooe-i is not identical to tree-i then it is a node of either left-i or right-i. In either 
of these cases, REASON has shown by induction that it is a member of a temporal 
collection generated by the occurrences of type leaf? within left-traversal or right- 
traversal. Since these occurrences are within a sub-segment of tree-traversal, they are 
sub-segments of tree-traversal itself. Thus all the nodes of tree-i are in the temporal 
collection generated by the occurrence s of test-leaf. et 


Section 8.51 Temporal Collection Data-flows 

Temporal collections are a useful abstraction mechanism only if they can serve 
not only as outputs of a segment but also as inputs. In this case, data-fiows between 
segments might involve the flow of a temporal collection output of one segment to a 
temporal collection input of a second segment This single data-flow statement is, 
however, an abstraction of the temporal behavior of the plan, summarizing many 
identifiable data-flows between sub-segments of the two plans. 


For example, in the temporal model of the fringe program we now have a sub¬ 
segment called tree-traversal which outputs a temporal collection containing the nodes 
of its input. This is connected by a data-flow link to sequential-accumulation which 
takes a temporal collection input This single link summarizes the fact that each 
occurrence of type leaf? within tree-traversal has a corresponding occurrence of cons in 
sequential-accumulation with a data-flow link connecting the two. 


sequential-accumulation can be given a simple set of specs saying that it takes as 
input a temporal collection and returns as output a single object which contains 
exactly the same members of the temporal collection 
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(defjijecs Sequential -Accumul at ion 
(inputs: col1ection-l) 

(expect: (Object-type collection-1 temporal-collection)) 

( output: 1ist-1) 

(assert: (for-all (:member-l) (member collection-1 :member-l) 

(member list-1 :member-l)) 

(for-all (:member-l) (member list-1 :member-l) 

(member collection-1 :member-l)))) 

The internal plan for sequential-accumulation is intuitively a cascade of cons segments, 
each taking one input from the temporal collection and the other input from the 
output of the preceding cons. The first cons takes nil as input and the last delivers its 
output as the output of the whole segment 

i 

i 


The-TenDoral-Col I action 



Sequential-Accumulation with Temporal Collection Input 

i 

In describing the tree-traversal plan fragment I needed the notion of a temporal 
collection being generated by the occurrence set of the same plan type. The 

sequential-accumulation fragment requires an inverse to this idea We may think of two 

distinct types of segments, those which generate a collection of values and those which 
utili;:'; the collection. In the first kind of segment it is convenient to talk about the 

occurrences of segments of a particular type generating a temporal collection; in the 

secon|d kind of segment, we require the notion of a temporal collection determining 
the cccurrences of sub-seginents of a particular type. When we say that a segment 
take^ a temporal collection as input, we are summarizing the idea that the objects in 
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the temporal collection are in a one to one correspondence with the members of an 
occurrence set within the segment. We refer to such an occurrence set as the 
temporal collection generated occurrence set, which we denote as follows 


(tc-gen-occ <p1an-type> <set-of-occurrence-name)) 

This allows us to represent the flow of objects of a temporal collection to a collection 
of occurrences by a single data-flow statement as is done in the statements of the 
following plan diagram (which is shown pictorially above): 


(defplan sequential-accumulation 
(sub-segments: init seq-acc-1) 

( flow-diagram: 

(dataflow (input sequential-accumulation the-temp-col) 

(input seq-acc-1 the-temp-col)) 

(dataflow (output seq-acc-1 the-answer) 

(output sequential-accumulation the-answer)) 

(dataflow (output init the-empty-1ist) 

(input seq-acc-1 the-initlal-value))) 

(constraints: 

(plan-type init generate-empty-1ist) 

(plan-diagram seq-acc-1 
( sub-segments: accum-op recur) 

(constraints : 

(spec-type accum-op accumulate-into-list) 

(plan-type recur seq-acc-1)) 

(flow-diagram: 

(dataflow (input seq-acc-1 the-temp-col) 

(input tc-gen-occ accum-op the-current-value)) 

(dataflow (output accum-op new-list) 

(input recur current-accum)) 

(dataflow (output recur the-answer) 

(output seq-acc-1 the-answer)))))) 

Notice that the data-flow links between the various occurrences of accum-op impose a 
temporal ordering on their execution which (in this case) is total. We require the 
ordering of elements of the temporal collection to be consistent with the ordering of 
the segments into which they flow. This is not an issue in the plan for fringe since 
the version of tree-traversal we are considering is so abstract that it specifies no 
ordering on the elements generated Its output and hence the input of sequential- 
accumulation is totally unordered; any mapping of the elements input to sequential- 
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accumjlation is consistent with the segment ordering of the occurrences of accum-op. 

However, if we were to consider a more specific tree-traversal, say one which 
tra\je rses in left-to-right, depth-first order, then there would be restrictions in the 
mapping; given two nodes, the node which is further to the left in the tree, will be 
mapped into an earlier occurrence of accum-op and will, therefore, appear earlier in the 
outp it of seo-acc- 1 . This requirement guarantees that the sequential-accumulation plan 
will not lose ordering constraints which were of significance to the segment which 
gen^ ated its inputs. 

REASON can prove that the sequential-accumulation plan satisfies its specs quite 
easi(k It once again uses (plan-type) computational inductioa In summary, the 
argA nent divides into two parts. The simple part is that if seq-acc-i satisfies its specs 
of Accumulating all the elements of its temporal collection input into the list which is 
its ^»ther input, then sequential-accumulation satisfies its specs trivially since all it does is 
to pi eate an empty list and then call seq-acc-i with this list as one argument and the 
temporal collection as the other. 

Now REASON assumes that all internal occurrences of seq-acc-i satisfy their 
speps. It follows that accum-op produces a list containing all members of the current- 
accuH jlat ion input plus the one additional element which is its other input This element 
is a| member of the temporal collection. The inputs to the recursive call of seq-acc-i 
are 1 he new accumulation and the remaining members of the temporal collection. By 
the ;pecs of seq-acc-i this will return a list containing all the objects which were 
meitibers of its list input plus all the objects which were members of the temporal 
collation input Thus, it produces a list of all the members of the temporal 
colit 'tion input to the main program. By induction REASON can conclude that seq- 
acc-i satisfies its specs. 

It follows that a plan which is a functional composition of tree-traversal with 
SEout itial-accumulation will produce a list of the nodes of the tree. If a filtering plan is 
put between them so that only the terminal nodes of the tree are members of the 
temporal collection output of the filter, then we will have a plan for computing the 
frinhs of the tree. It remains to show, however, that our original fringe program can, 
indq< d, be looked at in this way. 


For Complex Program Understanding 



156 


The Recognition Paradigm 


Chapter 9: The Recognition Paradigm 

The apprentice depends on a library of pre-analyzed plan fragments for use in 
analysis by inspection So far, I have presented a formalism which allows these 
fragments to be stated in a general and abstract manner. Fragments like tree-traversal 
or sequential-accumulation can be easily applied to any programming language and to a 
variety of data-structures and syntactic constructs which represent similar temporal 
behaviors. 

The apprentice uses pre-analyzed plan fragments to help explain parts of 
programs, matching sections of program code to particular fragments. If all parts of a 
program are mapped onto some plan fragment and if these fragments are connected in 
coherent ways and if the entire artifact so constructed implements a desired behavior, 
we can then say that the program has been analyzed. In such cases the plan 
fragments have been used as if they were proof rules (of a rather macro character), 
showing that their preconditions hold and asserting their conclusions. 

However, it will often be the case that only some of the code can be mapped 
onto fragments in the library of plans. In such cases it would be erroneous to assert 
that the program had been verified (or totally understood). Nevertheless, the program 
has been partially understood and half a loaf is better than none. 

The recognition process proceeds as follows. First, a simple language dependent 
process translates the source language program text into a plan diagram. Such 

programs have been developed for LISP by Rich [Rich & Shrobe, 1976] and for 
FORTRAN by Waters [Waters, 1977} This diagram, called the surface plan, is 
typically quite unstructured, having only that rudimentary segmentation which is 
implied by primitives such as if-then-else, do, cond, procedure-call etc. Data-flow links 
are deduced by a symbolic interpretation (developed by Rich in 

[Rich & Shrobe, 1976J of primitives such as assignment to variables, nested function 
applications etc. After this translation to plan diagrams, the raw code is not 
consulted, although links to it are maintained. 

A recognition mapping of this surface plan consists of an aggregation of some of 
its original segments into larger segments, a mapping of these to the segments of a 
library plan such that all plan-type and spec-type constraints of the library plan are 
satisfied by the surface plan segments, and such that the data-flow, control-flow and 
conditional-control-flows of the surface plan are consistent with those of the library 
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plan If such a recognition mapping can be constructed, it then follows that any 
property of the deep plan is also true of the corresponding surface plan. 

Actually, the above conditions are slightly too strong. In constructing a 
recognition mapping it is allowable to ignore some of the inputs or outputs of surface 
plan) segments. Data-flows connected to such inputs and outputs must also be ignored 
as rti.ist those spec clauses which mention such objects. Within the surface plan, sub- 
segnjimts which are connected to ignored inputs must also be ignored This allows us 
to separate a segment's behavior into those parts which involve a set of objects under 
con^i ieration and those which do not 

When we say that a surface segment satisfies a spec-type of the library plan we 
meah that we can select some of the input and output objects of the surface plan 
such that the I/O behavior of the library plan segment can be shown to hold for the 
aspett of the surface segment's behavior which involves only the objects selected. A 
simi|« x principle applies to saying that a surface plan segment satisfies the plan type of 
its Gc responding library plan segment 

Notice that a recognition mapping is not required to map every surface plan 
segment into a library plan segment However, if a set of recognition mappings have 
beep constructed such that each surface plan segment is in the domain of at least one 
completely constructed recognition mapping, then we say that the surface plan has 
beep completely recognized. 

^ will now proceed to show how the original fringe program can be completely 
nized as a composition of tree-traversal, leaf-filtering, and sequential-accumulation. 
-ving a sketch of this recognition process I will indicate how to extend the 
is of recognition so as to gain greater abstraction power. 

The construction of the recognition mapping depends on an inductive argument 
’ish to show that by ignoring the accumulation input, we may regard fringe as an 
ice of the tree-traversal plan. Ignoring the accumulation input forces us to ignore 
:cum-op segment, as well as the accumulation input to the two recursive calls. We 
hen construct the straightforward recognition mapping of test-leaf in fringe to 
test-|llaf in tree-traversal, left to left, right to right, and (right) left-fringe to (right) 
left-itiee-traversal. Each of these segments except the two fringe segments satisfy their 
spec ype constraints trivially. For the two fringe segments the induction hypothesis is 
invoked giving the desired result 


For Complex Program Understanding 







158 The Recognition Paradigm 



Join-Frinqd 


nr . 

1The-Fringe 




Recognition of Fringe as a Tree Traversal 


This partial recognition tells us that the temporal collection generated by the 
occurrence set of type leaf? within fringe includes exactly the nodes of the input tree. 
We now have to construct a partial recognition for the sequential-accumulation plaa 

The recognition mapping identifies the occurrences of the cons segment in fringe 
with the accum-ops of sequential-accumulation; the data-flows from test-leaf to the cons are 
mapped onto the temporal collection data-flow to the accum-ops. The remaining data¬ 
flows of the library plan for sequential-accumulation then require us to show that the 
first cons in fringe receives an empty list as its input, that the output of each 
occurrence of cons flows to the next occurrence, and that the output of the last 
occurrence of cons flows to the output of the whole segment 

The proof of these claims is a straightforward (plan-type) induction. We assume 
that the occurrence set of type cons within each internal application of type fringe is in 
fact a sequential-accumulation. There are two cases to consider. If the tree input to 
fringe is a terminal, then there is exactly one occurrence of cons; its inputs are the 
terminal node itself and the current-accumulation input of fringe; its output is the output 
of fringe. Thus, in this case all the requirements are met and we may regard the 
occurrence set of type cons as a sequential-accumulation. 
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Recognition of Fringe as Sequential Accumulation 


In the second case, the tree input to fringe is non-terminal and there are two 
recursive occurrences of type fringe. We can assume the induction hypothesis for both 
the left-fringe and right-fringe occurrences of fringe. We now construct a case 
analysis. By the induction hypothesis the occurrence set of type cons within each 
intek’ial application of type fringe is a sequential-accumulation. This leaves four special 
occw Tences of cons, namely the first and last occurrences within left-fringe and right- 
frin|; All other occurrences of cons cascade their outputs to the next occurrence and 
receive one of their inputs from the previous occurrence. 
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The special cases are handled easily (see diagram below). The data-flow from 
right-fringe to left-fringe implies that all occurrences of cons in right-fringe precede ail 
occurrences of cons in left-fringe. Thus, cons- 0 , the first occurrence of cons within 
right-fringe is the first cons within fringe; similarly cons- 3 , the last cons of left-fringe is 
the last cons of fringe. But the data-flow links of the fringe plan states that c-accum-b, 
the current-accumulation input to fringe, flows to the current-accumulation input to right- 
fringe. By the induction hypothesis right-fringe is an instance of sequential-accumulation, 
thus c- accum -0 flows to the first cons of right-fringe, Le to the first cons of fringe. 
Thus, the current-accumulation input to fringe flows to the first occurrence of cons within 

FRINGE. 

Similarly the data-flow links of the fringe plan state that the output of fringe is 
answer- 1 , the output of left-fringe. However, since by the induction hypothesis left- 
fringe is an instance of sequential-accumulation, its output, answer-i, is the output of 
cons-3, the last occurrence of cons within both left-fringe and fringe itself. Thus, 
the-answer output of fringe is the output of the last occurrence of cons within fringe. 

The two remaining special cases are cons-i, the last cons of right-fringe, and cons-2, 
the first cons of left-fringe. The data-flow links of fringe state that ansver-b, the 

THE-ANSWER output of RIGHT-FRINGE, floWS tO THE-CURRENT-ACCUMULATION input of LEFT-FRINGE. 

Again, by the induction hypothesis since answer -0 is the output of right-fringe, it is also 
the output of cons-i, the last cons of right-fringe. Similarly, since it is the input of 
left-fringe it is also the input of cons- 2 , the first cons of left-fringe. Thus, the output 
of cons- 1 flows directly to the input of cons- 2 , satisfying the induction requirements. 
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Details of Recognition: Fringe as Sequential Accumulation 

To complete the recognition of fringe as a tree -traversal composed with a 
tial-accumulation, the final thing we need to show is that the temporal collection 
it of tree-traversal flows to the temporal collection input of sequential-accumulation. 
rms of the recognition mapping which has been constructed, this means that the 
^ral collection generated by the occurrence set of type leaf? should flow to the 
rence set of type cons. Again this is a direct result of a simple inductive 
lent. If the input tree is a terminal then the result is trivial, there is exactly one 
flow between test-leaf, the one occurrence of type leaf? and the one occurrence 
pe cons. In the non-terminal case, the induction hypothesis says that there is a 
)ral collection data-flow between the occurrence set of type leaf? and the 
rence set of type cons in both left-fringe and right-fringe. But if the input tree is 
erminal, these are the only occurrences of type cons within fringe. It follows that 
:mporal collection input to the occurrence set of type cons within fringe is exactly 
iinporal collection generated by the occurrence set of type leaf? within fringe. 
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Thus, we have succeeded in mapping the fringe program onto the plan formed by 
a composition of tree-traversal with sequential-accumulation. As noted earlier, an 
immediate consequence of this result is the fact that the computed accumulation contains 
exactly the terminal nodes of the tree. 

It might seem at first glance that we have developed an extremely cumbersome 
technique where simpler methods might suffice. Two factors mitigate against this. 
First, much of the work we have shown here is illustrative only and would not be 
required in the actual routine recognition of programs like fringe. The cascade of two 
sequential-accumulations, for example, is so commonly used that it would be represented 
in the plan library as an instance of sequential-accumulation. Similarly, the plan library 
could include a plan called tree-traversal-&-action representing the general class of 
programs which, like fringe, which traverse a tree and act upon the nodes produced 
Thus, virtually all the work I have shown can be pre-proven and filed away. The 
actual recognition would be quite simple and involve little work. It should also be 
remembered that properties of tree-traversal and similar cliches are pre-proven. The 
apprentice separates the work of analyzing plans from that of analyzing programs, 
reducing the program understanding task to the relatively simple task of analysis by 
inspection. 

Section 9.1l Abstract Flows, Data and Control Pathways 

The strength of this method depends on the ability to abstract out details of the 
code in order to view the program as an instance of a more abstract but better 
understood artifact. Abstraction techniques allow the plans to achieve greater 
generality. So far we have seen techniques for abstracting procedural behavior (specs), 
various issues of data-flow (temporal collections) and control-flow (temporal control 
sequences). I will now add a further abstraction to the repertoire used in the plan 
diagram notation. This new feature called control-and data-pathways will allow the 
apprentice to recognize programs as instances of plans to which they bear little 

immediate resemblance. This will allow us to represent commonalities at a more 
abstract level 
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Consider the following program which computes the fringe of a tree using a 
breiildth first traversal. 
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On the other hand, there are obvious superficial differences, fringe is doubly 
ve in its surface syntax, whereas qfringe is a loop (singly recursive), qfringe has 

explicit queue while fringe has no similar explicit data-structure. Given the 

i ficial clues present in qfringe, any reasonable recognition process would first guess 
qfringe is an instance of the queue-ano-process plan shown below. 


For 


p QFringe(tree) 

(prog (Acc Node Q) 

(setq Q (Empty-Queue)) (Enqueue tree Q)) 

Ip (cond ((Queue-Empty? Q)(return Acc)) 

(t (setq Node (Dequeue Q)) 

(cond ((Leaf? Node)(setq Acc (cons Node Acc))) 
(t (Enqueue (left Node)) 

(Enqueue (right Node)) 

(go lp)))))) 


pse examination of the temporal behavior of this program reveals that it is quite 
to the fringe program of the previous section. In both programs there is a 
ersal of the nodes of the tree, a filtering of these nodes to select the leaf nodes, 
an accumulation of the leaves. This accumulation is the output of both processes, 
ict, the only significant difference between the two programs is the order of 
ersal of the nodes of the tree. However, since the library plan for tree-traversal 
no commitment to the order of traversal, it ought to be possible to recognize 
as an instance of the "fringe plan". 
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Consider the plan diagram for queue-and-process. The property of this diagram 
which seems most useful is that for any enqueued object there is an occurrence of 
dequeue in which this object is dequeued. Furthermore, every object dequeued is input 
to an occurrence of action. In summary, there is a sequence of occurrences taking 
each enqueued object to an occurrence of action. Such a sequence of events is merely 
an abstract data-flow; when we draw data-flow links in a library plan, what is of 
concern is that the object gets from one segment to the other. The actual method of 
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trail, mission is of little concern as long as we can believe that no significant property 
of 1:1 le transmitted object will be lost in the process. 

We will call such an abstract data-flow a data-pathway. A data-pathway may be 
formally defined as follows: 

Theie is a data-pathway of Obj-1 from application App-1 to application App-2 if there 
is a set of applications A and a set of data-flow links L such that: 

(i) Each data-flow link of L connects two applications of a. 

(ii) Each application of a either initiates or terminates a link of l. 

(iii) Under the temporal ordering imposed by the links of l, a has both a gib 

and and lub. 

(iv) obj-i is an output object of app-i which flows to an input of the gib 

of A. 

(v) obj-1 is an input object of app-2 which flows from an output of the lub 

of A. 

Thesi conditions intuitively state that there is a set of causally connected events in 
whidi obj-1 flows out of the first one and into the last Typically applications will be 
conn icted by data-flows of an object which contains obj-i as a sub-structure. The 
quern; in the above program plays this role. 
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Breadth First Fringe Program Using A Queue and Process Plan 
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It is easy to prove by computational induction that for any object which is a 
member of the input queue of an occurrence of queue-and-proces$-i there will be a data¬ 
path'say to an occurrence of process-member. It is also easy to show that qfringe is an 
insta ice of queue-and-process, mapping qfringe-i onto q-and-process-i and process-node onto 
proci:: s-member. Thus, for each member of the queue in an application of qfringe-i there 

will ae a data-pathway via a sequence of enqueues and dequeues to an occurrence of 
proce: S-NODE. 


If we regard these data-pathways as data-flows, we may then construct a 
nition mapping between qfringe and fringe. If tree-0, the input node, is non- 
nal then the test-leaf segment in qfringe will bring control to process-non-terminal. 
vill extract left-o, the left node of tree-®, and nql will make left -0 a member of 
lueue. right and nqr will act similarly on right-o, the right node of tree- 0 . 
*ol now passes to qfringe-i (i.e. we return to the beginning of the loop), with 
left-0 and right-0 members of the queue. By our remarks above, each of these 
via a data-pathway to another occurrence of process-node. Let us call these 
rences pn-i and pn-2 respectively. We can map pn-i onto left-fringe and pn -2 onto 
fringe, thus completing the recognition of qfringe as a fringe program. 
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The use of pathways becomes quite important in more complicated queue and 
based programs such as procedural deduction systems which rely on pattern 
ed invocation. In these programs, processes communicate by making assertions in 
ta-base possibly triggering other programs into executioa The notion of a 
ay makes the description of this mechanism far more concise than would be 
>le otherwise. Furthermore, it allows the system to understand such demon-based 
ims in terms of the communications between processes rather than in terms of 
lechanisin of communicatioa Pathways are analogous to the sometimes notion of 
a and Waldinger [Manna & Waldinger, 1976] in that they speak of control 
ing a certain point at some future time, rather than immediately; however, I use 
r ays as an abstraction tool which transforms one plan diagram into a second, 
easily recognized diagram. 


) Because pathways allow this greater flexibility, ail flow statements of a library 
nay be matched by pathways implemented in the surface plaa Library plans are 
in terms of data abstractions, specs, purpose links, data and control pathways. 
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Section 9.2! Summary 

The methodology I have outlined relies on developing a library of pre-proven 
plan fragments which capture substantial parts of the knowledge of an expert 
programmer. Once such fragments have been catalogued, the effort of program 
anah sis may be reduced to that of recognition. I have not discussed what heuristics 
would guide such a recognition system, interesting work in that direction is being 
conducted by Rich [Rich, 1977] and Waters [Waters, 1977]. Instead I have 
concentrated on the how such a process would interact with the reasoning capabilities 
of the program analysis system. 

Our method might be challenged on the grounds that it involves as much work 
as more standard approaches to program verification. However, this work is factored 
in two ways which are highly significant First, we divide the task into (1) Pre- 
proving frequently used standard plan fragments whose logical analysis need never be 

repeated, and (2) Recognizing the occurrences of these fragments within more complex 
programs. 

Second, the recognition process itself is factored into many discrete steps, such 
as: (1) Showing that each of the proposed segments of the surface plan satisfies the 
type constraints of the library plan, (2) Showing that the data-flows of the surface 
plan implement the data-pathways of the conceptual plan. While the total amount of 
work involved might be substantial it is separated into "bite sized" pieces; furthermore, 
the framework allows the reasoning system to self-consciously concentrate on the 
particular goal at hand at that moment While attempting one particular recognition 
all other parts of the program can be ignored. 
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Chapter 10: Description of Data-Structures 

So far I have presented methods of describing various components of 

prog amming knowledge; I have also shown the irious reasoning techniques used in 
REASON to operate on these descriptions. In this chapter I will develop a language 
for describing the static properties of data-structures. In the next chapter (which will 
disci ss side-effects) I will describe REASON'S methods for reasoning about how 
properties of data-structures change. 

Knowledge about data-structures is a key component of the knowledge base 

need id by the programmer's apprentice system. This knowledge is used by the 

synthesis and recognition systems in a declarative form. In the reasoning part of the 
system, descriptions of data-structures are used in a more active or procedural manner. 

Data-structures are perhaps the most flexible items in the apprentice's knowledge 
base; programmers routinely devise new data-structures and new methods of 
implementing them. It is crucial that a convenient language be developed for the 
description of data-structures. This language allows the programmer to tell the 
apprentice about new data-structures, their decomposition into parts and the 

constraints which these parts must satisfy. Finally, it allows the programmer to devise 
new relationships which might be true of the new data-structure and to provide the 
appre ntice with definitions of these new relations. 
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The data-description language has two main features. First, it is syntactically 
-ative, allowing the programmer to describe objects without having to know the 
>ased syntax of the deductive system. The declaratives are translated by 
>ON into rules which actually make the deductions. Second, the description 
age allows hierarchical knowledge structures and inheritance of properties. An 
can be described as a special kind of list which in turn is described as a special 
of recursive-structure. Properties are described at the most general level possible, 
ally the programmer need only state that the structure he is designing is a 
1 case of some other (or of several other) structured). Each aspect of the 
ted behavior of the newly defined structure is then mapped down from the 

t structure(s). Usually, only a few new properties are involved in the definition 
V new object. 
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Section 10.1: The Data-Description Language 

At the Invest level, a data-structure is something which has specific parts subject 
to certain constraints. For example, a list is usually described as having a first and a 
rest subject to the restriction that the rest must be either another list or a terminator 
such as NIL. A binary-tree, similarly, has a left and a right where both are required to 
be either binary-trees or terminals. These ideas are represented by two types of 
assertions: part and type-restriction : 

(Part <object-type) <part-name>) 

(Type-restriction (<part-name> <object-type>) <object-type)) 

For example, 


(Part List First) 

(Part List Rest) 

(Type-restriction (Rest List) List) 

Object-types are sets of similarly structured objects such as list or binary-tree and 
are subject to the normal set operations of union, intersection, set difference, etc. In 
particular, we use the subset relation extensively to build a hierarchy of knowledge. 

For example, lists are linear-objects, and property-lists are lists. This is stated as 
follows: 


(Subset list linear-object) 

(Subset property-list list) 

Two useful pieces of information are extracted from such statements by 
REASON'S rules. First, anything which is a subset of an object-type is itself an 
object-type; second, anything which is a member of a subset of an object-type is a 
member of the larger type as welL 
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(rule 

((:« (subset :subtype : supertype))) 

(as * 1 rt '(object-type :subtype) 

'(subset-implles-type :a))) 

(rule ((:a (subset :subtype :supertype)) 

( :b (type :object :subtype))) 

(assert '(type :object :supertype) 

'(type-chain :a :b))) 

Object-types are often combined to yield new types. For example, we might 
want to have an object-type which includes both empty- and non-empty-lists. This 
object-type might be called list. However, it is also useful to distinguish between 
empty- and non-empty-list; therefore, we also have the two specialized object-types called 
empty list and non-empty-list. Obviously, list is the union of the other two object- 
types, in addition the intersection of empty-list and non-empty-list is the null set Such 
a situation is so common in defining object-types that I have distinguished it with the 
special name partition. We write this as follows: 

(partition List into: (Empty-List Non-Empty-List) ) 

from which it follows that: 

(Subset Empty-List List) 

(Subset Non-Empty-List List) 

(Uniar (Empty-List Non-Empty-List) List) 

(Intersection (Empty-List Non-Empty-List) Null-Set) 

It is usually insufficient to know only that an object-type is partitioned; we also need 
to krow how to distinguish between the sub-types. The partition of list into empty 
and f on-empty exhibits a very frequent and common method of distinction, namely that 
one (»f the sub-types has a more detailed part structure. Sometimes, however, a more 
invob ed criterion is used to distinguish sub-types. For example, we may partition 
lists into cyclic-list and acyclic-list 

usin ; a much more complicated criterion. Two syntactic extensions to the partition 
statement are provided to facilitate the stating of these restrictions. 
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The first of these is the allows clause, written as follows: 


(Partition list 

into: (empty-list non-empty-1ist) 

(allows: non-empty-list (first rest))) 

The allows clause says that the named sub-type (non-empty-list, in this case) includes 
the part names mentioned in its set of part names; furthermore, this is a distinguishing 
characteristic within the given partition. In the example above this means that non¬ 
empty-lists can be distinguished from empty-lists by the presence of either a first part 
or a rest part. 

We can now give a simple description of list: 

(Partition list 

into: (empty-list non-empty-list) 

(allows: non-empty-list (first rest))) 

(Part List First) 

(Part List Rest) 

(Type-Restriction (Rest List) List) 

similarly we can give a description of binary-trees as follows: 

(Partition Binary-Tree 

into: (Terminal Non-Terminal) 

(allows: non-terminal (Left Right))) 

(Part Binary-Tree Left) 

(Part Binary-Tree Right) 

(Type-Restriction (Left Binary-Tree) Binary-Tree) 

(Type-Restriction (Right Binary-Tree) Binary-Tree) 

If the criterion which distinguishes between sub-types is more complex, we 
express this with a dividing criterion clause. For example, we can tell acyclic-lists 

from cyclic-lists by the absence of any sub-list which is a sub-list of itself. This is 
stated as follows: 

(Partition list 

into: (acyclic-list cyclic-list) 

(dividing-criterion: 

(For-All (:sub) (sub-list acyclic-list :sub) 

(not (proper-sub-list :sub :sub))))) 
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The data-description language uses several notational conventions which are 
shown in this example. The dividing criterion clause above mentions acyclic-list. 
This use of a type name within a statement of the data-description language is an 
implicit quantification over any object of that type. I will explain this notation 
furtner in the next section. In the case of the dividing-criterion clause, however, the 
meai ing is quite simple. Any object of the partitioned type (say list) which satisfies 
the hviding- criterion (the for-all statement) can be deduced to be of the sub-type 
mentioned in the criterion (acyclic-list). 

Now let us move on to other definitional statements. Closely related to the 
notion of part is that of indexed-part which is used to describe objects like arrays 
havir g many similar sub-structures distinguished by numerical indexing rather than by 
name. The index is permitted to be any tuple of integers, but in practice I will 
almo;t always be talking about single dimensioned indexed-structures. indexed-parts, like 
parts, are subject to type restrictions. This is written as follows: 

( Indei ed-Part <object-type> <indexed-part-name>) 

(Type Restriction (<mdexed-part-name> Cob ject-type>) <object-type>) 

Thus an array of integers would be described as follows: 

(Obje<t-Type Integer-Array) 

( Indei ed-Part Integer-Array Item) 

(Type Restriction (Item Integer-Array) Integer) 

Some restrictions, however, are of a type which is difficult or awkward to describe as 
type restrictions. For example, the object used to index an indexed-structure is required 
not only to be an integer tuple of the appropriate "a-rity" (a type restriction), it is 
also required to be w’ithin the correct bounds. Describing this as a type restriction 
would require the creation of an object-type for every range of integers. Instead 
these more complex restrictions may be stated directly with a require statement: 

(Reqir re 

(Iten Integer-Array index object) 

(Index Integer-Array index)) 
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which states that if an object is used as the selecting position of an indexed-part 
statement, then it must be a valid index of the object whose component it selects. 
The notion of index must, of course, be defined elsewhere (see later section on relation 
definitions). Require statements are invariants which state that any time their first 
clause is true, their second clause must be as well Thus, there are two ways to make 
use of the information encoded in such a statement The first is to deduce the 
consequent from the antecedent; the second is to require that the consequent hold any 
time the antecedent is realized through a side-effect 

type-restrictions may be regarded as a special case of require statements in which 
the antecedent is a part or indexed-part statement and in which the consequent is an 
object-type statement In fact, both types of statements are translated into REASON 
rules in a rather straightforward manner which makes this clear. For example, the 
above require statement leads to the following: 

(Rule ((:a (Item :is :index :obj)) 

(:b (type :is indexed-structure))) 

(Assert '(Index :is :index) '(require :a :b c))) 

where c is the fact-name of the require statement Similarly a type-restriction would 
be translated into the following: 


(Rule (( :a (Left :bt :node)) 

(:b (type :bt binary-tree))) 

(Assert '(Type :node binary-tree) '(type-rest :a :b c))) 

where c is the fact-name of the type-restriction statement 

Given these means for describing the component structure of an object-type we 
may now go on to define properties and relations of data-objects. Consider a binary- 
tree; we would like to describe what it means to be a node of such a tree. We do this 
with a simple recursive definition: a node of a non-terminal binary-tree is either the tree 
itself or a node of the left of the tree or a node of the right of the tree. The only nooe 
of a terminal binary-tree is the tree itself, this is represented as follows: 
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imp 1 


Relation-Definition (node non-terminal binary-tree) 

<=> (or (id non-terminal binary-tree) 

(node [left non-terminal] binary-tree) 

(node [right non-terminal] binary-tree))) 

Relation-Definition (node terminal binary-tree) 

<=> (id terminal binary-tree)) 

'e that assertions of the data-description language do not use REASON variables 
: non - terminal) but only simple identifiers (e.g. non-terminal). This is a notational 

mience which is possible since REASON translates these statements into REASON 
which do use variables. 

There is a second notational shorthand involved here. Each identifier (Le. 
thing olher than the logical operators and the predicate names) used in a data- 
iption statement is an object-type (e.g. binary-tree, non-terminal, etc.). This allows 
ons to be poly-morphic , i.e. one relation (such as member) may apply to many 
ent pairs of object-types, member, for example, is a relation which holds between 
and objects, hash-tables and entries, alists and dotted-pairs, etc. The use of 
t-tvpes as the identifiers of the relation-definition restricts the applicability of the 
ition to exactly those cases where the objects involved satisfy the type constraints 
sd by the identifiers, (identifiers may actually be subscripted object-types such as 
rminal-i in those cases where there is more than one object of a type mentioned 
n a single relation). It is important to remember that this notational principle 
is only to statements of the data-description language, not to REASON’S rules, 
l data-description assertions are translated into the rules of the reasoning system, 
requirements implicitly represented by the identifiers of the data description 
nent are made explicit as triggers of the rule. 

relation-oefinitions are used in a number of ways in REASON, corresponding to 
arious ways in which implications can be used in logic systems. The simplest of 
is the substitution of a right hand side for the left REASON translates the 
1 definition into the following rule which will make this substitution if requested 
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(Rule 

((:e (expand ((node :nt :bt) :s)))) 

(Rule 

((:a (( node : nt :bt) :s)) 

(:b ((non-terminal :nt) :s)) 

(:c ((binary-tree :bt) :s))) 

(Assert '(Or (id :nt :bt) 

((node <[1eft :nt] :s> :bt) :s) 

((node £[right :nt] :s> :bt) :s)) 

'(Rel-def :a :b :c F-l)))) 

In this rule there are two levels of invocation. The outer level is triggered by an 
explicit request to expand the assertion. This creates the inner rule which checks to 
see if, in fact, the assertion to be expanded is believed and then checks to see if the 
type-constraints are satisfied. If so, the definition is asserted and justified by the 
triggering facts. However, if the type-constraints are not satisfied then this rule 
represents an inappropriate definition and no assertion is made. 

A second use of relation-definitions is in the antecedent deduction of a relation 
such as member from the facts corresponding to the right hand side of the definitioa 
For example, the following is the standard recursive definition for membership in a 

LIST. 

F-3 (Relation-definition (Member List Object) 

<=> (or (first list object) (member [rest list] object))) 

This definition has the following antecedent use; if we know that an object is the 
first of a list, or if we know that it is a member of the rest of the list, then we can 
infer that it is a member of the list. This corresponds to two rules which REASON 
creates from this definition; 


Dependency Directed Reasoning 




10.1 The Data-Description Language 177 


(Rule* 

(( ((first :1 :o) : s) ) 

( 4 ((type : 1 list) : s ))) 

(a$4«rt '((member :1 :o) :s) '(Rel-def :a :b F-3))) 

(Rule 

((((rest :1 :r) :s)) 

( : t) ((member : r : o ) : s )) 

( :tj ((type :1 list) :s))) 

(as^< rt '((member :1 :o) :s) '(Rel-def :a :b :c :d F-3))) 

Notice that in the second rule REASON translated the reference expression [rest list] 
into a pattern in the trigger set of the rule. All reference expressions within the 
clauses of a relation-definition are handled in this way; recursively nested expressions 
are brought out to the top level, member in a hash-table is such a relatioa A hash-table 
is an iNDEXED-sTRucTURE in which each component (called a bucket) is a set, represented by 
some data-structure. There is a functional relationship called hash which maps entries 
into indices of the table. An entry is a member of the table if it is a member of the bucket 
into which it hashcs. 

F-4 (Fel ation-Definition (member hashtable entry) 

I <=> (member [bucket hashtable [hash entry]] entry)) 

Thi^ definition is translated into the following rule. 

(Rule 

((:al ((Member :b :e) :s)) 

(:a2 ((type :e entry) :s)) 

(:a3 ((type :b bucket) :s)) 
j (:a4 ((hash :e :index) :s)) 

( :a5 ((bucket :t :index :b) :s)) 

(:a6 (type :t hashtable) :s)) 

(assert '((member :t :e) :s) 

'(rel-def :al :a2 :a3 :a4 :a5 :a6 F-4))) 

Such rules are built by first replacing the reference expressions by equivalent 
existentially quantified statements and then transforming the statement in clausal form. 
Each disjunct of the resulting expression is then translated directly into a rule with 
the ;t of conjuncts forming the trigger set 
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We should note that relations, like parts, are subject to type-restrictions. These 
restrictions are represented with the same notation as type-restrictions on parts and 
inoexeo-parts. For example: 

(Type-Restriction (node binary-tree) binary-tree) 

which would be translated into a rule as shown earlier. 

It is a rather common practice to build up new data-types by imposing 
restrictions on already existing types. A common example is that of a LISP 
association list (a-list for short) which is a list all of whose members are pairs. We 
indicate this as follows: 

(defining-restriction 
(subset al ist 1ist) 

(type-restriction (member alist) pair)) 

Several distinct types of information are extracted from such a statement First, there 
is the obvious subset relation between alist and list, and the fact that the type- 
restriction applies to the alist data-type. A simple rule adds these new facts-* 


(rule 

(( : a (def ining-restriction :subset-fact :type-res-fact))) 

(assert :subset-fact '(def-rest :a)) 

(assert :type-res-fact '(def-rest :a))) 

However, there is a further piece of information in the defining-restriction which 
is used in a consequent (backward chaining) manner. For example, if one wishes to 
show that an object is an alist, one possible strategy is to first show that it is a list 
and then show that it satisfies the defining restriction of having only pairs for members. 
The following rule embodies this strategy. 
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(ru l|e (( : a 1 (goal ((Object-type :object alist) :s) for : goal in :context)) 

(:a2 (defining-restriction (subset alist list) (type-restriction (member alist) pair)))) 

(propose-method 

'(Method :al (defining-restriction :a2)) '(def-rest :al :a2) 

(Assert 

'(conjunctive-goals (object-type :object list) 

((for-all (:el) ((member :object :el) :s) 

((object-type :el pair) :s))) 

(:« 2 ) 

(((object-type :object alist) :s) . :goal) 

:context) 

'(defining-restriction :al :a2)))) 

wheie the conjunctive-goal mechanism is explained in Chapter 4. Notice that if the 
system does conclude that an object is an alist, this conclusion will not depend on the 
control assertions created during the process but only on the object-type assertion, the 
for-aL assertion, and the defining-restriction statement 


Section 10.2! Parameterized Object Descriptions 

The statements I have shown so far allow us to state specific features of a data- 
structure; however, a descriptive method which "chunks" such statements into larger 
pare< ls of knowledge would be desirable. Such chunks of knowledge can then be 
organized into a library of programming skills [Rich & Shrobe, 1976], [Barstow, 1977] 
in si ch a way that generalities are conveniently captured and specialized as needed. 
The basic unit of description in this system will be a parameterized object description, 
whioi is a collection of statements describing the structure of a data-object The 
parameters in an object description allow it to describe a family of related data-types. 
The object-types set-of-numbers, set-of-lists, and unrestricted-sets are all defined by the 
same parameterized description, only the choice of parameters is changed. This is 

quite similar to features found in CLU [Liskov, et aL 1977] and ALPHARD 
[Wu|r f et al. 1976} 
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(Object-type-definition Set 

(parameters: Members-type (type-restriction: object-type)) 
(partition Set into: (non-empty-set empty-set) 

(Allows: Non-Empty-set (Member))) 

(Relation (Member set members-type)) 

(type-restriction (Member set) Members-type) 

(Relation (Union Set Set Set) 

(definition: (Union S-l S-2 S-3) 

< = > (Equiv ( :el ) (or (member s-l :el)(member s-2 :el)) 
(member s-3 :el)))) 


| ) 

I 

The equiv quantifier above is merely an abbreviation for two universal quantifiers, 

one in each direction. REASON, in fact, treats these as abbreviations, translating 

; the,n int0 the two quantifiers when the object-type definition is read in. 

In this definition, set takes a single parameter which is required to be an object- 

tv pe name. This name is then used at various points in the definition, for example in 

I the type-restriction statement Such parameters act like the arguments to a macro 

| generator; the type definition for set may be invoked with a specific parameter causing 

a more specific type to be created in which the parameter is instantiated The 
l following illustrates the syntax for such invocation: 

(set (whose: (members-type: pos-number))) 

which means the more specific object-type which consists of sets whose members-type 
parameter is pos-number. Presumably, pos-number is a valid object-type and therefore this 
new type is as well. Inspection of the description indicates that this new object-type 
allows only pos-numbers as members, since the members-type parameter is used in the type- 
restriction statement Similarly, 

j (set (whose: (members-type: neg-number))) 

would be the object-type of sets of negative numbers. The convention is made that 
unspecified parameters assume a default value of unrestricted, so that the object-type 
specified as set with no parameters is treated as a set whose members may be of any 
object-type. Notice that parameters are given with type-restrictions; in practice 
parameters are usually restricted to be either object-type names or numbers. 
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To avoid writing out the rather cumbersome type expressions above I have 
ded an is-a statement to give a name to such expressions. Thus, we could write: 

:t- type-definition Set-of-Pos-Numbers 
» (set (whose: (members-type: pos-numbers))))) 

lever an object- type expression is used (either in is-a clauses or elsewhere) an 
itiation process is invoked to add this new object-type into the hierarchy of 
t-types. This invocation process consists of the following steps: 

iVhen the definition is first entered an object-type is created whose name is the 
given in the definition statement and whose parameters are the default values, 
will be referred to as the base-type, e,g. set. 

rhe new type is given a name. If used within an is-a clause the name is taken 
the clause. Otherwise, a default name is created. 

rhe new type is declared to be a subtype of the base-type, defining-restrictions 
dded to reflect the effect of the specified parameters. For example, in the set- 

-numbers object-type, the oefining-restriction is the type-restriction of members to pos- 
s. 

^irarneter values are substituted for parameter names, and the new object-type 
is substituted for the base-type name. Each statement within the definition is 

processed. Those whose parameters are specified are asserted; those with default 
s are not. 

If there were unspecified parameters, the partially instantiated object-type 
tion is added to the catalogue of object-type names. It, in turn, may serve as a 
type for further instantiation. 

[t is often convenient to be able to describe a related family of objects, using 
iques similar to those above. For example, we might want a parameterized way 
scribing numeric-intervals, using the upper and lower bounds as parameters. Each 
itiation of this description is a particular object (not an object-type, as above), 
:ach such object differs only in minor regards from other such objects. Such 


descriptions are made with a parameterized object description- 
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(Object-definition Numeric-Interval 
(Parameters: (Upper-bound (type-restriction: Integer) 

Lower-bound (type-restriction: Integer)) 

( restriction : (Less-than Lower-bound Upper-bound))) 

; (Is-a: (Set (whose: (Members - type: Integers)))) 

(definition: (Numeric-Interval (whose: (upper-bound: U)(lower-bound: l))) 

= {: e 1 | (And (less-than :el U)(greater-than :e1 L))})) 

| Like object-type descriptions, object descriptions take parameters subject to certain 
restrictions. The is -a clause allows us to give an object-type name to any object 
j described by this parameterized description. Finally, the definition clause states an 
equality which defines what objects are named by the current description. 

i 

i 

Object descriptions are processed as follows: 

(0) A new object-type is created using the name in the description as the type-name, 
(for example, numeric-interval above). 

(1) If there is an is-a clause, the object-type name is asserted to a sub-type of the 
type named in the clause. 

(2) Any invocation of the description which leaves some parameters unspecified 
creates a new object-type (for example, numeric-intervals whose lower bound is 0). 

(3) An invocation which specifies all parameters creates an object which is asserted to 
be equal to the object specified in the definition clause. Finally, if the parameter-set 
for this object is a more specific set than the one used to create the next less specific 
object-type, then the object is asserted to be of that object-type. (For example, the 
numeric interval whose upper bound is 5 and whose lower bound is 0 would be 
asserted to be of the object-type of numeric intervals whose lower bound is 0 and 
whose upper bound is unspecified). 

Section 10.3: Implementation and Virtual Objects 

One object can be used to simulate the behavior of another. In fact, 

implementing more abstract data-structures using simpler ones is a great part of the 
effort in symbolic programming. Most often we use data-structures to represent basic 
mathematical concepts such as sets, sequences, mappings, graphs, and multi-sets. However, 
there are a host of ways to build any of these representations. sets may be 
represented by lists, arrays, or hash-tables; mappings by lists-of-pairs, pairs -of -arrays, hash- 

TABLES-OF-PAIRS, etC. 
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The data-description language, therefore, requires two further extensions. First 
we must have a means of describing an implementation method; second, we need a 
way of stating that a particular abstract object is implemented using a particular 
method. Let us consider the classic example of implementing a stack using an array 
and a pointer. (What thesis could be complete without a stack implemented as an 
arra^ and a pointer?) Let us say that we define a stack to be an object with two 
par^j, a top and a history, where the history is required to be another stack (empty or 
non-^ipty). We may describe this as follows: 


(Impl :mentation-Method Stack-As-Array 
(Abs :ract-Object: Stack) 

(Cot :rete-Objects : 

(Implementing-Array 
(type-restriction: 

(Array (whose: (members-type: [Members-type Stack]))))) 

(Implementing-Pointer 
| (type-restriction: Integer)) 

(restriction: (Index Implementing-Array Implementing-Pointer))) 
(Rep esent: (Top Stack Object) 

(d! inition: (Top S 0) 

<=> (Item Implementing-Array Implementing-Pointer 0))) 


Before giving the rest of the method let us look at what we have so far. We say that 
one object may be represented by the behavior of a set of other objects using the 
ABSTit; ct-object and concrete-object clauses. These, of course, include type and other 
restrictions which establish the pre-requisite conditions of the representation. We then 
describe how each of the undefined relations of the abstract object is mapped onto 
relations involving the concrete objects. This is done in the represent clause using 
equivalence statements like those used to define relations. 

| An implementation method implicitly defines a new object-type, namely objects 
of the abstract type which are implemented according to the specific method. This 
object-type is given the name of the implementation-method. Thus, we can build the 
following REASON rules which relate properties of objects of the abstract type to 
profje rties of objects of the concrete types: 
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(rule ((:fl ((Object-type :S1 Stack-As-Array) : s i t)) 

(:f2 ((Implementing-Array :S1 :A) : s i t)) 

(:f3 ((Implementing-Pointer :S1 :I) : s i t)) 

( :f4 ((item :A : I :0) : s i t))) 

(Assert '((Top :S1 :0) :sit) 

'(Implementation :fl :f2 :f3 :f4 :f5))) 

(rule {( : f0 (expand ((top :S1 :0) :sit)))) 

(rule ((:fl ((Object-type :S1 Stack-As-Array) :sit)) 

(:f2 ((Top :S1 :0) :sit))) 

(Assert '((item [Implementing-Array :S1] 

[Implementing-Pointer :S1] :0) :sit) 

'(Expand-Imp :fl :f2)))) 

Notice that each concrete object in an implementation-method is given a name; this 
allows us to refer to the concrete objects by their description e.g. "the implementing- 
array of stack-41". This bears such a similarity to the ways in which parts are used 
that I refer to this as an implementation part. When a new method is described, 
assertions are added to the knowledge base stating what the implementation parts are: 

(Implementation-Part Stack-As-Array Implementing-Pointer) 

(Implementation-Part Stack-As-Array Implementing-Array) 

The corresponding type-restriction statements are also added to the knowledge base. 
These are then used in exactly the same way as are part statements and their type- 
restrictions. Also notice that the object-type implicitly defined by an implementation- 
method is a subtype of the abstract type. When a new method is entered into the 
system an assertion like the following is added to the data-base: 


(Method-for Stack Stack-As-Array) 

this triggers the following rule: 

(Rule ((:f (Method-for :type-l : type - 2))) 

(Assert '(Subset :type-2 :type-l) 

'(method-implies-subset :f))) 

We still need to define how the history (sub-stack) part of the stack is 
implemented. Intuitively we want to say that the history is the stack implemented by 
(1) The same array and (2) The number which is one smaller than that of the current 
stack. In the data-description language, therefore, we let the implementation-method name 
be a special operator. A predicate beginning with an implementation-method name 
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includes a an object name and a whose clause for each implementation-part-name. For 
example, 


(Sta{::-As-Array (whose: ( Implementing-Array: A1)(Implementing-Pointer: Nl)) Stack-1) 

mears that stack-i is the stack implemented by the array ai and the number N2, using 

method stack-as-array. Thus, we may now describe how the history is represented 
a t ing: 

sent: (History Stack Stack) 
nition: (History SI S2) 

<=> (Stack-As-Array (whose: 

(Implementing-Array: [Implementing-Array SI]) 

(Implementing-Pointer: 

[plus 1 [Implementing-Pointer SI]])) S2))) 

Usidj; the techniques I have shown so far, this is turned into the following rule: 
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((:fl ((Object-type :S1 Stack-As-Array) :sit)) 

( : f 2 ((Implementing-Array :S1 :A) :s i t)) 

( : f 3 ((Implementing-Pointer :S1 :N1) : s i t)) 

( : f 4 ((Plus 1 : N1 :N2) :sit)) 

(:f5 ((Object-type :S2 Stack-As-Array) :sit)) 

( :f6 ((Implementing-Array :S2 :A) :sit)) 

( : f 7 ((Implementing-Pointer :S2 :N2) :sit))) 

(Assert '((History :S1 :S2) :sit) 

'(implementation :fl :f2 :f3 :f4 :f5 :f6 :f7))) 

The represent clauses in implementation-methods are handled almost exactly like 
on-definitions. In the next chapter, I will discuss how REASON analyzes side- 
s, discussing the problems posed by defined relations extensively at that point 
reader should bear in mind that by defined relations I mean both relation- 
tions and the equivalences given in the represent clauses. 


Before moving on to a brief catalogue of object-type descriptions, I should 
obsejrve that the terms abstract object and concrete object used in implementation-methods 
bit of a misnomer. Indeed, sometimes arrays are used to implement other arrays, 
i|ig the notion of abstract and concrete fuzzy at best This type of representation 
jcjden in the above example about stacks, where we talked about the history. This 
fact, nothing but another array represented as a sub-array of the first 
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It is a well known technique (used in sorting programs for example) to divide a 
single array into sub-arrays, using indices to separate the conceptually distinct "virtual" 
arrays. Thus, given an array and two numbers (a and b) which are indices of that 
array we can represent another array of size (b - a) as follows: The ith element of the 
virtual array is the (a + i)th element of the concrete array. This is expressed as 
follows: 

( Implementation-method Array-Segment 
(Abstract-Object: Array) 

(Concrete-Objects: 

( Implementing-Array (type-restriction: 

(Array (whose: (members-type: [members-type Array]))))) 

(Lower-Index (type-restriction: Integer)) 

(Upper-Index (type-restriction: Integer)) 

(restriction: (> [size Implementing-Array] [size Array]) 

(Index Implementing-Array Lower-Index) 

(Index Implementing-Array Upper-Index) 

(> Upper-index Lower-Index) 

(Plus lower-index [Size Array] Upper-Index))) 

(represent: (item array number object) 

(definition: (Item A N Obj) 

<=> (item Implementing-Array [plus lower-bound N] Obj)))) 
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Section 10.4 1 A Catalogue of Object Descriptions 

Ibo far, I have introduced a number of mechanisms for the description of objects, 
s section I will present a systematic development of REASON’S knowledge about 
First, I will state the basic mathematical knowledge about sets, mappings, etc. 
I will define several basic programming data-structures, leading up to lists, trees 
ssociative-retrieval hash-tables like that coded in the scenario. 
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will begin by defining set as an object-type with membership, union, intersection, 


(Obj^ct-type-definition Set 

(pqrjameters : Members-type (type-restriction: Object-type) 

Size (type-restriction: Pos-Number)) 
tition: Set into: (Non-Empty-Set Empty-Set) 
allows: Non-Empty-Set (member))) 
ation: (Member Set Members-type)) 
e-restriction (Member Set) Members-type) 
triction: (Cardinality Set Size)) 
ation: (Union Set Set Set) 
finition: (Union S-l S-2 S-3) 

<=> (Equiv (:el) (Or (Member S-l :el)(Member S-2 :el)) 

(Member S-3 :el )))) 
ation: (Intersection Set Set Set) 
finition: (Intersection S-l S-2 S-3) 

< = > (Equiv (:el) (And (Member S-l :el)(Member S-2 : el)) 

(Member S-3 :el)))) 

ation: (Set-Minus Set Set Set) 
finition: (Set-Minus S-l S-2 S-3) 

< = > (Equiv (:el) (And (Member S-l :el)(Not (Member S-2 :el))) 

(Member S-3 :el)))) 
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(Relation: (Equal Set Set) 

(definition: (Equal S-l S-2) 

<=> (Equiv (:el) (Member S-l :el) 

(Member S-2 :el)))) 

(Relation: (Size Set Pos-Number) 

(definition: (Size S N) 

<=> (If (Object-type S Empty-Set) 
then (Size S 0) 
else (For-all (Member S :el) 

(Size [Set-Minus S { :el}] 

[Minus N 1])))))) 

Notice that in the definition of size, I introduced the braces (< ...}) notation for set 
presentation. REASON (using the macro character facilities of MacLisp) translates 
this notation into the form which is used internally. Set presentation with braces can 
take either of two forms, extensional or intentional in the former the set is presented 
by listing its members within the braces: 


{ 1259 } 

Intentional presentation defines the members of a set as those objects which satisfy a 
formula with one free variable. The variable is given before a vertical bar | and the 
sentence afterwards. For example, the set of pigs with wings is presented as follows: 


{:x| (and (pig :x)(winged :x))} 

In the internal form, these are represented as follows: 


(Extensional-Set <ti$t of Objects) Set) 

(Intentional-Set :variable Pred Set) 

for example. 

(Extensional-Set (1259) S-l) 

(Intentional-Set :x (and (pig :x)(winged :x)) S-2) 

which say respectively that s-i is the set of the numbers 1 2 5 and 9 and that s -2 is 
the set of pigs with wings. 
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The following set of REASON rules interpret these assertions: 


(Rul* 


((:f ( Intentional-Set :var :pred :set))) 

(Assert '(object-type :set Set) '(Int-Set-Type :f)) 

(Rule ((:f : pred )) 

(Assert '(Member :Set :Var) '(Int-Set-Mem :f :g)))) 


(Rule 


((:f ( Intentional-Set :var :pred :set)) 

(:g (Not : pred))) 

(Assert '(Not (Member :set :var)) '(Int-Set-Not-Mem :f :g))) 



((:f (Extensional-Set :Iist :set))) 

(Assert '(object-type :set Set) ' (Ext-Set-Type :f)) 

(Mapc '(Lambda (x) 

(Assert '(Member :$et ,x) '(Ext-Set-Mem :f))) 

: T1st)) 


(Rul* 


((:f (show (not (member :set robject)) by (ext-set) 
for :goal in :context)) 

( :g ( extensional-set :list :set))) 

(Or (member :object :1ist) 

(Assert '(Not (member :set :object)) '(ext-set-not-mem :g)))) 


(RuH 


(( :f (goal (Member :set :obj) for :goal in .-context)) 

(:g (Intentional-Set :var tpred :set))) 

(Propose-Method 

'(Method : f ( Int-Set :g)) '(IntSet :f :g) 

(let ((:new-pred (subst :obj :var :pred))) 

(goal-assert :new-pred '((Member :set :obj) . :goal) 


:context '(Int-set-subgoal :f :g))))) 


whejrp 
stati 

precjibate. 


the above is a consequent 
that a sufficient sub-goal 


rule which is used only when requested. It simply 
is to show that the object satisfies the defining 


For 
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The next mathematical object-type in REASON'S knowledge base is mappings: 

(Object-type-definition Mapping 
(parameters: domain-type (type-restriction: object-type) 
range-type (type-restriction: object-type)) 

(is -a : (Set 

(whose: (members-type: (association 

(whose: (key-type: domain-type) 

(value-type: range-type))))))) 

(Relation: (Image Mapping domain-type range-type) 

(definition: (Image Map Key Value) 

<=> (There-is (:el) (Member Map :el) 

such-that (And (Key :e! Key)(Value :el Value))))) 

(Relation: (Domain Mapping (Set (whose: (Members-type: domain-type)))) 

(definition: (Domain Map D) 

< = > (Id D <: e1 | (There-is (:as) (Member Map :as) 

such-that (Key :as :el ))>))) 

(Relation: (Range Mapping (set (whose: (members-type range-type)))) 

(definition: (Range Map R) 

< = > (Id R <: e 11 (There-is (:as) (Member Map :as) 

such-that (Value :as :el))})) 

(Relation: (Range-Element Mapping Range-type) 

(definition: (Range-element Map R) 

<=> (Member [Range Map] R))) 

(Relation: (domain-E1ement Mapping domain-type) 

(definition: (domain-element Map R) 

<=> (Member [domain Map] R))) 

Notice that I used the notion of an association (or pair) in defining a mapping. 
following defines associations: 


(Object-type-definit ion Association 
(parameters: Key-type (type-restriction: object-type) 

Value-type (type-restriction: object-type)) 

(parts: Key (type-restriction: Key-type) 

Value (type-restriction: Value-type))) 

I will now define two more specific kinds of mappings, namely functions and 
mappings. 


The 


-TO-l 
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jejc t-type-def inition Function 

efji ling-restriction: (subtype function mapping) 

rejs triction: (For-all (:d) (domain-element Mapping :d) 

(there-is-a-unique (: a s) (Member Mapping :as) 
such-that (key :as :d)))))) 

ject-type-definition 1 - to-1-Mapping 

efi ling-restriction: (sub-type 1-to-l-mapping function) 
restriction: (For-all (:r) (Range-element function :r) 

(there-is-a-unique (:as) (member function :as) 
such-that (value :as :r)))))) 

e that since functions are mappings and i-to-i-mappings are functions, each of these 
:>e invoked with the domain-type and range-type parameters specified in the mapping 
tioa 


sequence is a mapping from a numeric-interval to a set: 


(Ob jejc 
(Parja 


mea 

seque 1 


t-type-definition: Sequence 

neters: Sire (type-restriction: Pos-Integer) 

Members-type (type-restriction: Object-type)) 

: (Function 

(whose: (domain: 

(Numeric-interval 
(whose: (lower-limit: 0) 

(upper-limit: size)))) 

(range-type: Members-type))) 

Bme: (Range-e1ement to: Member) 

(domain-element to: Index)))) 

Notice that I used a rename clause within the is-a expression above. This simply 
> that what was called range-element in the type function is called member in the type 
:e. REASON copies in the old definition, substituting member for range-element. 

The description of sequences makes use of the notion of a numeric-interval which 
[ready been given in the text; I will repeat it here as well: 


For 
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(Object-clef inition Numeric - Interval 
(Parameters: (Upper-bound (type-restriction: Integer) 

Lower-bound (type-restriction: Integer)) 

(restriction: (Less-than Lower-bound Upper-bound))) 

(Is-a: (Set (whose: (Members-type: Integers)))) 

(definition: (Numeric-Interval (whose: (upper-bound: U)(lower-bound: L))) 

= { :e1J (And (less-than :el U)(greater-than :el L))))) 

A sequence of particular importance (particularly in describing arrays) is a sequence of 
positive integers of a given size. Since I will use such objects in defining arrays I will 
need to define a notion of one such sequence being within the bounds established by 
another such sequence (e.g. a sequence of indices being within the array bounds). 


(Object-type-definition Sequence-of-pos-integers 
(Parameters: Size (type-restriction: Pos-Integer)) 

(Is-a: (Sequence (whose: (Members-type: Pos-Integer) 

(Size: size))) 

(rename: Image to: Item)) 

(Relation : (In-bounds Sequence-of-Pos-integers Sequence-of-Pos-integers) 

(definition: (In-bounds S-l $-2) 

<=> (For-all (:index) (Index S-l :Index) 

(Less-than [Item S-l :Index] [Item S-2 :Index]))))) 

I will now define arrays as they are found in MacLisp (all dimensions are positive 
integers). 


(Object-type-definition Lisp-Array 
(Parameters: dimension (type-restriction: Pos-Integer) 

Upper-bound (type-restriction: 

(Sequence-of-Pos-Integers (whose: (size: dimens ion)))) 
Members-type (Type-restriction: object-type)) 

( Indexed-part: Item (type-restriction: Members-type) 

(Index-restriction: Index 

(type-restriction: (Sequence-of-Pos-integers (whose: (size: dimension)))) 
(restriction: (Within-bounds Index Upper-bound)))) 

(Relation: (Index-of Lisp-Array 

(Sequence-of-Pos-IntegerS (whose: (size: dimension)))) 
(definition: (Index-of Array Seq) 

<=> (Within-bounds Seq Upper-bound)))) 
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ASH I 


(ObjcK 

(P«r|) 


No\^ 


For 


now move to a more complicated data-structure, namely hash-coded data-bases. 

; are several such systems, the features common to all of them is the use of a 
g-function and an array. I will start by defining a hash function. 

t-type-definition hash 

meters: domain-type (type-restriction: object-type) 
size (type-restriction: pos-integer)) 

: function (whose: (domain-type: domain-type) 

(range: (numeric-interval: 

(whose: (lower-bound: 0) 

(upper-bound: size))))))) 

simplest hashing system is one which calculates a hash from the entire data-base 
The next simplest is an associative system which calculates the hash on the key 
af the data-base item. Both these insert the item into a single place in the data- 
A more complicated system will be described later. 

t-type-definition hashtable 

meters: Members-type (type-restriction: object-type) 
size (type-restriction: pos-integer) 
hash (type-restriction: (hash 

(whose: (domain-type: Members-type) 

(size: size))))) 

: (lisp-array (whose: (members-type: 

(set: (whose: (members-type: Members-type)))) 

(size: size))) 

(rename: item to: bucket-part)) 
tion: (Member hashtable Members-type) 
inition: (Member ht el) 

<=> (Member [bucket-part ht [hash el]] el)))) 

for the associative version of hash-tables: 
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(Object-type-definition associative-hashtable 
(Parameters: key-type (type-restriction: object-type) 

value-type (type-restriction: object-type) 
sire (type-restriction: pos-integer) 
hash (type-restriction: 

(hash (whose: (domain-type: Key-type) 
(size: sire)))) 


(is-a: 

(1isp-array 
(whose: (members-type: 

(set: (whose: (members-type: 

(association (whose: (key-type:key-type) 

(value-type: 


(sire: sire ))) 

(rename: item to: bucket-part)) 

(Relation: (Member hashtable Members-type) 

(definition: (Member ht el) 

<=> (Member [bucket-part ht [hash [key el]]] el)))) 


value-type))))))) 


So far I have not dealt with recursively defined structures such as lists, trees, graphs, 
etc. I will develop these by first defining an object-type called recursive-structures. I 
will then define lists, trees, etc. as special cases of this object-type. 
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t-type-defimtion Recursive-structure 

ition: Recursive-Structure into: (terminal non-terminal) 

(allows: non-terminal (Immediate-chi 1dren))) 

recursive structure is always built from the "recurring parts" which are 
ailed the non-terminals and the "stopping parts" which are called terminals. 

meters: value-names (type-restriction: set)) 
s: Immediate-Children (type-restriction: 

(set: (whose: 

(members-type: Recursive-structure)))) 

Values (type-restriction: (association: (whose: (domain: value-names))))) 

he definition is parameterized by a set of "values" which are other fields 
resent at each node, but which are not involved in the recursion 

ow make the basic definitions. The immediate children are the first 
evel of recursion, i.e. the nodes pointed to directly by the current node 
tion: (immediate-child recursive-structure recursive-structure) 
inition: (immediate-child rs-1 rs-2) 

< = > (Member [immediate-children rs-1] rs-2))) 

proper node is one gotten to via an immediate child link, 
tion: (proper-node recursive-structure recursive-structure) 
inition: (Proper-node rs-1 rs-2) 

<=> (Or (immediate-child rs-1 rs-2) 

(there-is (immediate-child rs-1 :ic) 
such-that (proper-node :ic rs-2))))) 

ode is the transitive closure of immediate child. I.e. anything you can 
et to by first going to an immediate child and then its immediate child, etc. 
tion: (node recursive-structure recursive-structure) 
inition: (node rs-1 rs-2) 

<=> (or (proper-node rs-1 rs-2) 

(id rs-1 rs-2)))) 
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;;; A terminal node is a node which is a terminal. It stops the recursion, 
(relation: (terminal-node recursive-structure recursive-structure) 

(definition: (terminal-node rs-1 rs-2) 

<=> (and (node rs-1 rs-2)(object-type rs-2 terminal)))) 

;;; Non-terminal nodes are the other guys. 

(relation: (non - terminal-node recursive-structure recursive-structure) 

(definition: (Non-terminal-node rs-1 rs-2) 

<=> (and (node rs-1 rs-2 )(0bject-type rs-2 non-terminal)))) 

;;; If all the non-terminal nodes have the same number of immediate children, 

;;; this number is called the node degree. Lists have node degree 1, binary 
;;; trees have node degree 2; some graphs have no degree by this def. 

(relation: (Node-degree Recursive-structure Pos-integer) 

(definition: (Node-degree RS N) 

<=> (For-all (Non-terminal-Node RS :Node) 

(Size [Immediate-Children :Node] N)))) 

;;; two structures share if they have a common node. This is very important 
;;; for reasoning about side-effects. 

(relation: ( shares-structure recursive-structure recursive-structure) 

(definition: (shares-structure rs-1 rs-2) 

< = > (There-is (proper-node rs-1 -.node) 

such-that (proper-node rs-2 :node)))) 

;;; if you can find a node somewhere in this structure which is a node of itself 

;;; in a non-trivial way (nodes were defined to be nodes of themselves) then the 

;;; structure has cycles. This is usually very bad. 

(relation: (has-cycles recursive-structure) 

(definition: (has-cycles rs-1) 

<=> (There-is (node rs-1 :node) 

such-that (proper-node :node :node)))) 

;;; Structures can be divided into those with cycles and those without 
;;; notice that structures now have two different partitions. 

(partition: recursive-structure into: (cyclic-structure acyclic-structure) 
(dividing-criterion: (Has-cycles cyclic-structure))) 
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;;; Tie rule of structural induction can be applied to any acyclic structure 
;;; to prove that some property holds for all of its nodes. 

(proof rule: 

(goa : Property 

(where: (occurs-in Property :var) 

(object-type :var acyc1ic-structure))) 

(sub|oals: (for-all (:term)(terminal-node acyclic-structure :term) 

,{subst :term :var property)) 

(for-all ( :non-term) (non-terminal-node acyclic-structure :non-term) 

(implies 

(for-all ( :child)(immediate-child :non-term :chi Id) 

.(subst :child :var property)) 

.(subst :non-term :var property)))))) 

This s the only object-type definition so far where I have found it useful to include a 
proof- iule with the definition. The syntax is, therefore, somewhat ad hoc, REASON 
builds a consequent reasoning rule and a method-proposer from this statement The 
method-proposer will trigger if there is a goal statement which includes an object 
which is an acyclic-structure. If the method is accepted, it creates the two sub-goals 
of showing that (1) The property holds for all terminal-nodes of the object and (2) If it 
holds for all immediate-children of a nooe then it holds for the node itself. Notice the use 
of cc ininas (,) in front of the subst expressions to indicate that they should be 
evaluated (i.e. subst is to be invoked as a function; it is not a predicate name). 
structjral-induction is also used on binary-trees and lists, but the rule is simply copied 
into their definitions since they are defined as special kinds of recursive-structures. 
[Boyer & Moore, 1975,77] uses structural induction extensively to prove theorems in 
recursive function theory and Pure Lisp. 

^ext I will define a binary-tree as a special kind of acyclic-recursive-structure whose 
immeo i |ate-children is a set of two binary-trees. 

-type-definition Binary-tree 
: Left (type-restriction: binary-tree) 

Right (type-restriction: binary-tree)) 

(Acyclic-structure (whose: (Node-degree: 2))) 

(Immediate-children binary-tree) 

: ([left binary-tree][right binary-tree])))) 
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Notice the use of the map clause above. Remember that whenever a object is 
defined with an is -a clause the system copies all the information about the super-type 
into the new definition. The hap clause tells REASON that any expression involving 
immediate-thildren in the definition of recursive-structures should be replaced by an 
identical expression involving the extensionally presented set above. This can be 
regarded as an equivalence saying that if a binary-tree is thought of as a 
recursive-structure then the set of immediate-children is the set composed of the left of 
the tree and the right of the tree. In a binary-tree the immediate-children part is a 
virtual object composed of the two "real" parts, the left and the right. 

Finally, I will define a list as a data-type with two parts: a first and a rest. 
The chain of rests forms a recursive-structure. There is a substantial private 
vocabulary associated with lists, which is indicated by the rename clauses. As above, 
the map clauses are used to indicate how this structure satisfies the definition of 
recursive-structures. A new construct, the singleton type is introduced to take care of 
the fact that in LISP the only possible empty-list is the special object nil. A 
single ton-type consists of one object; therefore, any object known to be of that type is 
also know to be the unique object of that type. Finally, several relations peculiar to 
lists are introduced. 
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(Objett-type-definition List 

(Parameters: Members-type (type-restriction: Object-type)) 

(Pars: First Rest (type-restriction: List)) 

( par' ition : List into: (Empty-list Non-Empty-1 ist) 

(allows: Non-Empty-List (first rest member))) 

(sin< leton-type: Empty-list object: Nil) 

(is*): Recursive-structure (whose: (Node-degree: 1)) 

(mail : ((immediate-children list) into: {[rest list])) 

((values list) into: {(first . [first list]))))) 

(rerame: (node to: sublist) 

(terminal to: empty-list) 

( non-terminal to: non-empty-list) 

(non-terminal-node to: non-empty-sublist) 

(terminal-node to: empty-sublist))) 

(relation: (Member List Members-type) 

(definition: (Member L 0) 

<=> (Or (First L 0) 

(Member [rest L] 0)))) 

(function: (Length List Pos-Integer) 

(definition: (Length L N) 

<=> (if (Object-type L Empty-List) 
then (id N 0) 

else (Length [rest list] [Minus N 1] )))) 

(relation: (Comes-before-in List Members-type Members-type) 

(definition: (Comes-before-in L 0-1 0-2) 

<=> (There-is (Sublist L :Sub) 

Such-That (And (First :Sub 0-1) 

(Member [Rest :Sub] 0-2)))))) 

Notice that in the map clause, the values part of the recursive-structure is mapped onto 
the pairing of the name "first" with the first part of the list. 

The final object I will present is the CONNIVER-style associative-retrieval 
hashi ig system. This is an array each of whose items are lists. The array holds 
assertions which are binary-trees. An assertion is a member of the table if it is a member of 
each 3ucket hashed to by any of its terminal-nodes. 
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(Object-type-definition Conmver-hash-table 
(Parameters: size (type-restriction: pos-integer) 
hash (type-restriction: 

(hash 

(whose: 

(domain-type: (pair: (whose: (left: Atom) 

(right: Pos-Number)))) 

(size: size))))) 

(is-a: (lisp-array (whose: (members-type: 

(set: (whose: (members-type: binary-tree-of -atoms)))) 

(size: size))) 

(rename: item to: bucket-part)) 

(Relation: (Member hashtable Binary-Tree-of-Atoms) 

(definition: (Member ht el) 

<=> (for-all (:node) (terminal-node el :node) 

(for-all (:pos) (position-in ht :node :index) 

(Member [bucket-part ht [hash :node :index]] el)))))) 

The full-blown programmer's apprentice system will have an even more extensive 
catalogue of descriptions; however, my point here is not so much to present the 
complete catalogue used in REASON, as to show how the reasoning system gets its 
information. The compete catalogue used by the apprentice is being worked on by 
Rich [Rich, 1977,78]. It is also for this reason that I did not include spec-types for 
the various operations associated with object-types as is done in data-abstraction 
languages. The final catalogue will do so, but for the reasoning system's purposes this 
is not necessary. 
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Chapter 11: Reasoning About Side-effects 

The ability to change the structure of an object while leaving its identity 
unchanged provides a powerful mechanism for modularity ai.d abstraction in advanced 
programming languages such as LISP. However, precisely because side-effects on 
global and shared structures possess such potential power, they also allow enormous 
room for error. When a segment causes a side-effect it saves itself the worry of 
communicating with a hoard of other segments which might access the same structure, 
but t does so at the price of requiring an assurance that it is safe to make the 
proposed change. This assurance, unfortunately can only be gained by engaging in a 
non-local and expensive form of reasoning. 

Simple changes can result in non-trivial results, something every experienced 
programmer has learned the hard way. Since complex structures are built from less 
complex objects, it follows that a side-effect to a part of a structure can change 
properties of the whole structure. Even worse, since complex structures may share 
sub-structure, a modification to one data structure might change a property of some 
other data structure which had been thought of as a completely separate object In 
reaso ling about the results of a particular action, REASON must assess what 
properties besides those explicitly stated will also change. 

In the context of common sense reasoning in AI this general problem has been 
termed the frame problem in [McCarthy and Hayes, 1967 & 69] and has received a 
considerable degree of attention [Raphael, 1970], [Hayes, 1971a & b\ An example 
will llustrate the problem. Suppose I tell you that the saucer was taken to the 
kitch ;n. If you knew that the cup was on the saucer, then you would probably infer 
that the cup was now in the kitchen; the inference would probably be correct since 
there is a causal relationship between the location of the cup and the location of the 
saucer upon which it is placed. However, you would also never think to ask whether 
the saucer had changed color when it was removed to the kitchen, since motion has 
little to do with position. 

In common sense reasoning, one has to assume that most things don't change 
unles; there is strong reason to believe that they do. When such assumptions lead to 
trouble, one re-examines his current belief system and rearranges things to correspond 
to thfs realities. In the case of program understanding, similar techniques also apply. 
Consider the following procedure for swapping the first element of two lists of 
numbers without using a temporary variable: 
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(defun swap (1 t st-1 list-2) 

(rplaca list-1 (- (car list-l)(car list-2))) 
(rplaca list-2 (+ (car 1 ist-1)(car list-2))) 
(rplaca list-1 (- (car list-2)(car list-1)))) 


a brief explanation of this procedure might be helpful Suppose that the car of list-i 
is a and the car of list -2 is b. Then the sequence of additions and subtractions leaves 
the following values in the first position of the two lists: 


initially 
first subt 
addition 
2nd subt 


list-1 

a 

a - b 
a - b 
b 


list-2 

b 

b 

a 

a 


reason 


b ♦ (a - b) = a 
a - (a - b) = b 


Interestingly enough, this program has a bug; furthermore, few programmers (even 
experts) spot the bug when examining the program. (The reader might try to figure 
out what the problem is now before proceeding). 

The problem is illustrated by considering what this program will do if called with 
the same object for both arguments: 


(swap list-23 list-23) 


Since the formal parameters list-i and list -2 are bound to the same object, the 
procedure fails, putting 0 into the car of list- 23 . The fact that most programmers fail 
to spot this bug indicates that they are assuming that the two arguments are distinct 
lists, even though they have no evidence supporting this assumption. 

This indicates that, as in common sense reasoning, programmers use more than 
one strategy for analyzing the effect of an action. In the more reckless strategy, one 
assumes that things are not changed unless there is reason to believe they do. This 
has the advantage of being right most of the time, requiring less effort, and allowing 
the programmer to form a "first order" theory of what the code does. In the more 
careful strategy, one does the opposite, assuming things are affected unless evidence to 
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the contrary exists. This, has the advantage of never allowing a false conclusion to be 
drawn, but the disadvantage of requiring much greater effort, to the extent that it can 
prevent one from forming a "first order" understanding. In developing REASON, I 
have experimented with two protocols corresponding to these two forms of analysis. I 
will present these protocols after presenting some notational preliminaries in this next 
section. 


Section 11.1: Specifying Side-effects 

REASON allows special kinds of spec clauses to facilitate the description of 
side-effects. The two such basic clauses are side-effect and new which have the 
following format: 


(Side-Effect changed-object Input-Sit Output-Sit New-clause) 
(New New-Object Input-Sit Output-Sit New-Clause) 


The 
to tf 
whicl 
state: 
open 
the r 


irst of these states that on the transition from the input situation of the segment 
e output situation of the segment the changed-object is subjected to a side-effect 
makes new-clause true in the output situation. The second type of assertion 
that a new object is brought into existence (through use of the cons or related 
tions) on the transition from the input to the output situation of the segment; 
ew object satisfies the property stated in new-clause. 


Within a segment's specs clauses the transition part of these statements is omitted 
since it can unambiguously be inferred by the symbolic interpreter. Thus, in specs 
one may write 


(Side-effect object clause) 

(New object clause) 

liince a side-effect changes properties of an object we would like a simple way to 
talk about the object both before and after the side-effect is performed. We already 
have one mechanism, the object state description «object situation) which allows us 
to distinguish between input and output states of the object However, for notational 
simpl city we also introduce another method. We allow the outputs clause to create a 
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second name for an input object, as follows: 


(outputs: (new-name id-to input-name)) 


This new name is referred to as the output name, whenever it is used in an assert 
clause, it implicitly refers to the object in the output situatioa Notice that spec 
clauses are usually stated without explicit situation tags since these can be provided by 
the symbolic interpreter using simple defaulting rules. 

The specs for a simple side-effect like rplacd can be stated as follows using this 
notation: 


(defspecs rplacd 
(inputs: a-list new-rest) 

(expect: (object-type a-list list)) 

(outputs: (the-new-1ist id-to a-list)) 

(assert: (side-effect a-list (rest the-new-list new-rest)))) 

In evaluating a set of specs, the symbolic interpreter builds a mapping which 
matches input and output ports to objects. An output port mentioned in an id-to 
clause is bound to the same object as is the input port of the clause. In the course 
of interpreting the spec clause, the interpreter replaces input and output ports by the 
objects to which they are matched Also the interpreter examines whether there are 
any output port names in the clause; if so, and if the clause is not explicitly tagged 
with a situation name, the output situation is added in. Thus, assuming that rplacd 
were applied to list- 1 and rest-i in s-a, resulting in the new situation s i, the above 
side-effect clause would actually be asserted as: 


(side-effect list-1 S-0 S-l (rest list-1 rest-1)) 

This defaulting mechanism is quite useful in describing side-effects which relate some 
property which is true of the object on input to some property true upon exit For 
example, we might want to increment by 1 some count field of a particular 
data-structure. We would then say that the count field in the output situation is 1 
plus the count field in the input situatioa This, of course, involves a reference 
expression; the same defaulting rules apply here, if the reference expression mentions 
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no Oitput port it is defaulted to the input situation. 


(defspecs bump 
(inputs : a-record) 

(expect : ... ) 

(outputs: (the-new-record id-to a-record)) 

(assert: 

(side-effect a-record 

(count the-new-record [plus i [count a-record]])))) 


Assuming that the segment is applied to record-i in s -0 yielding s-i this is asserted as: 


(sid4 


effect record-1 S-0 S-l 

(count record-1 {[plus 1 {[count a-record] S-0) ] S-0})) 


Notite that in making the defaults a reference expression which is resolved in the 
inpujt situation is regarded as an input name, while one resolved in the output 
situation is regarded as an output name and will force any enclosing expression to be 
regaled as an output expression. This is not always convenient but it can always be 
overbidden by use of explicit object-state descriptions or fully spelled out reference 
expressions. For example, the LISP function nreverse may be described as follows: 


(defspecs nreverse 
(inputs: a-list) 

(expect: (object-type a-list list)) 

(outputs : new-list) 

(assert: ((last-cell a-list newlist) *before*) 

(reverse <a-list *before*> <new-list *after*>))) 


wheite 
the 
The^e 
of iip 
strudt 


as mentioned in Chapter 5, ^before* and *after* are special symbols provided by 
tinbolic evaluator to stand for the input and output situations of the segment 
specs state that (1) the output list was the last cell of the input list at the time 
ocation of the segment and (2) that the output list at the time of output has a 
lire which is the reverse of that possessed by the input list at the time of input 
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It should be noted that although the side-effect and new clauses are special in the 
sense that they are explicitly trans-situational assertions, they are otherwise normal. 
In particular, side-effect clauses can be part of a quantified statement For example, 
we might want to say that certain members of a set (those having a particular key) 
were side-effected to turn on a particular mark. (This is done in one version of a 
fast-intersection routine). This can be expressed as follows: 


(defspecs mark-some 
(inputs: the-list the-key) 

(expect: (object-type the-list list) 

(object-type the-key key)) 

(outputs: (the-new-1ist id-to the-list)) 

(assert: 

(for-all ( :member) (member the-new-list .-member) 

(implies (key :member the-key) 

(side-effect :member (marked :member)))))) 


This quantified statement is treated in exactly the same manner as other statements; it 
is asserted after the objects have been substituted for the input and output port 
names. Asserting a for-all statement, as we have seen in Chapter 4, creates a rule 
which triggers if its pattern is matched. This, in turn will create a rule for the 
implies statement, which triggers if its pattern is matched. If both these patterns are 
matched, (which is equivalent to saying that we know about a particular object which 
both is a member of the list and has the appropriate key) then the system will 
conclude that a side-effect definitely took place, namely that this member of the list 
was marked. 


Section 11.2: Reasoning About Simple Side Effects 

Reasoning about side effects is conceptualized by thinking of the segment as 
forming a transition between its input and output situations. Side-effect processing 
consists of deducing which properties can be moved across this transition safely; I, 
therefore, refer to this process as transition analysis. My general approach of explicitly 
recording dependencies suggests that REASON should provide a justification whenever 
it decides to move a fact across a transition. Similarly, if it decides not to move a 
fact it should justify this decision as welL These recorded dependencies allow 
REASON to make an initial decision based on a cursory analysis of the circumstances, 
while still reserving for itself the option of reconsidering in more detail at a later 
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time. 

The basic protocol is as follows: An assertion in the input situation of a 
transition can be moved to the output situation of the transition only if there is an 
explicit assertion declaring it safe to do so. In phase one of the analysis, simple rules 


are 


.in to find reasons for not moving a fact If such cause is found, these rules 


assert 
assert 
non4 
if a4 


that it is unsafe to move the fact At the end of this process each assertion is 
d to be safe to move; however, the justification for this safe assertion is 
onotonic, depending on the or/mess of the corresponding unsafe assertioa Thus, 
reason for considering the assertion unsafe had been found, the unsafe assertion 


will be in, causing the safe assertion to be out. If at the end of this process a safe 
assertion is in for a particular fact, then the fact will be asserted in the output 
situation with its justification pointing to the safe assertioa The following rules carry 


out (these operations: 
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The Default Assumer for the Careful Protocol 

(rule (( :f (side-effect robject :in-sit :out-sit :new-fact)) 

( :g (:old-f act :in-sit)) 

( :h (transition :in-sit :out-sit))) 

(assume '(not (safe :g :in-sit :out-sit)) 

'(safety-first :f :g :h))) 

The Default Assumer for the Fast and Dirty Protocol 

(rule ((:f (side-effect :object :in-sit :out-sit :new-fact)) 

( :g (:old-fact :in-sit)) 

( :h (transition :in-sit :out-sit))) 

(assume '(safe :g :in-sit :out-sit) 

'(reckless-abandon :f :g :h))) 

The Safe Fact Hover 

(rule ((:f (safe :o1d-fact :in-sit :out-sit)) 

(.old-fact (:fact :in-sit)) 

(:g (transition :in-sit :out-sit)) 

(Assert '(:fact :out-sit) '(safe-from-side-effeet :f :g))) 

Make The Side-effect Appear In The New Situation 

(rule ((:f (side-effect :object :in-sit :out-sit :new-fact))) 

(assert '(:new-fact :out-sit) 

'(side-effects-happen :f))) 

where the last of these merely asserts that the relation stated in the side-effect 
assertion is true in the output situation; this is, of course, independent of the safe 
assertions. 

. I have not yet shown any rules for determining what is safe and what is not 
The simplest such rule is the rule of direct negation which says that a fact which is 
explicitly negated by a side-effect is unsafe: 
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record 
asser 
asser 




mvo 


(rule (( : f (side-effect :obj :in-sit :out-sit (not :fact))) 

( :g (:fact :in-sit))) 

(Assert '(not (safe :g : i n - sit :out-sit)) 

'(direct-negation :f :g))) 

Another simple side-effect rule concerns objects with parts. Suppose that a 
is modified to change one of its parts to a new value. It follows, that the 
ion stating the old value of the affected part of the record is not a safe 
ion. The following rule states this fact: 


(rule ((:f (side-effect :object :in-sit :out-sit 

(:part-name :object :new-value))) 
( :g ((object-type :object :type) :in-sit)) 

(:h (part :type :part-name)) 

(:i (('.part-name :object :old-value) :in-sit))) 
(assert ’(not (safe :i :in-sit :out-sit)) 
'(part-side-effect :f :g :h :i))) 


rules 

and 


level 
objeb 
strut 
by i 




iA second rule is that a part-replacing side-effect cannot affect a part assertion 
ing a different part-name. 


(rule ((:f1 (side-effect :object-l :s-l :s-2 

(:new-part-name :object-l :new-part))) 

(:f2 {{:old-part-name :object-2 :o1d-part) :s-1))) 

(cond 

((eq :o1d-part-name :new-part-name)) 

(t 

(assert '(safe :f2 :s-l :s-2) 

'(diff-part-side-effect :fl :f2))))) 

also exists for the independence of indexed-part assertions from part side-effects 
ice versa. 


The next rule is for side-effects to indexed-parts. This rule introduces a new 
of complexity due to the presence of incomplete knowledge. Suppose we have an 
with an indexed structure (for example, an array, a hash-table, or a record 
^ure including an array) and that this object is modified changing the part indexed 
Ex-o. Also suppose that we have an assertion saying what is the part indexed by 
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INDEX-1. 



Then, the side-effect should make the assertion unsafe if the two indices are identical 
and leave it unaffected otherwise, as expressed in the following rule: 


(rule ((:f (side-effect :object :in-$it :out-sit 

(:indexed-part-name :object :new-index :new-value))) 

(:g ((object-type :object :type) :in-sit)) 

( :h (indexed-part :type : index-part-name)) 

(:i ((:indexed-part-name :object :old-index :o1d-va!ue) :in-sit))) 

(assert '(if ((equal :old-index :new-index) :input-sit) 
then (not (safe :i :in-sit :out-sit)) 
else (safe :i :in-sit :out-sit)) 

1 (indexed-part-side-effect :f :g :h :i))) 

This creates an if-then-else assertion whose justification points to the statements 
relating to the side-effect. If the premise of the if-then-else (the equality of the two 
indices) is determined to be true (false), then the then (else) clause of the if-then-else is 
asserted. Its justification includes the if-then-else assertion and the equal assertion or 
its negation. 

Notice, however, that it is altogether possible that neither the premise of the 
if-then-else, nor its negation are present in the data base and thus, that neither a safe 
nor an unsafe assertion will be created. Later in this chapter we will see an example 
where, due to hypothetical reasoning, it is not possible to know whether the two 
indices are equal or not, since one of them is an anonymous object, standing for a 
”typical" index of the array. 
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This has a very important impact on the protocol for side-effect processing. 
Rech 1 that this process goes through two passes, the first of which is "fast and dirty" 
(corresponding to what most programmers would notice without explicitly considering 
’screv-baU" cases). The second pass is more careful and includes an examination of 
oddb ill cases of aliasing (like the swap example, shown earlier). The crucial point 
here is that, in the first pass analysis, we consider a fact safe unless evidence to the 
contrary is found. 

If we have an indexed-part side-effect as above, and it cannot be determined 
whetier the two indices are equal, then the rule shown above will make no assertion, 
(Le. neither a safe not an unsafe assertion). But in the first pass "fast and dirty" 
ana^sis, this lack of an unsafe assertion will be taken as grounds for assuming that 
the \i ssertion is safe; it will, therefore, be moved across the transitioa This will not 
be logically incorrect, since the justifications for the assumption are explicit and can 
be withdrawn; it is, however, not a very useful strategy. Even for a fast and dirty 
pass this strategy is a little too dirty. It would be more useful to say that if it is 


but 

equ«1 

the 


possible that the two indices are equal, then we should not consider the assertion safe, 
j;hould rather do a case analysis, considering separately the two possibilities of 
ity and non-equality. 


Since the conclusion that the assertion is not safe is based on the possibility that 
ndices are equal, we need a way of asserting that this possibility exists; this 
possibility assertion can then be included in the justification. Because the notion of 
poss 



is used quite frequently, I have developed some syntactic mechanisms to 
facilitate the use of the concept The starting point is the observation that an 
asseirion is possible as long as its negation is out; of course, if the assertion is in it is 
also possible. Thus, the following support structure captures the notion of possibility: 


F-2 


F-3 (Possible ((Equal Index-0 Index-1) S-l)) 




\ 


Not ((Equal Index-0 Index-1) S-l)) 


F-l ((Equal Index-0 Index-1) S-l) 
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This structure is created by calling the function is-possible with f-i as argument 
Calling is-possible does not make f-i in nor does it make the negation of f-i out it 
simply creates a support structure which says that if f-i is in or if f-i's negation, f-2, 
is out then f -3 should be in. The result of this is that if f-i is possible and is-possible 
is called with f-i as argument then the assertion f -3 will be in. 

Given this, we can extend the rule for indexed-part side-effects to be more 
cautious by adding the following to its body: 

(is-possible ((equal :old-index :new-index) : input-sit)) 

(rule ((:f (possible ((equal :old-index :new-index) :input-sit)))) 

(assert 

(not (safe ( :indexed-part-name :object :old-index :old-value) 

:in-sit :out-sit)) 

(careful-indexed-part :f))) 

This says that if it is at all possible that the indices are equal, then the indexed-part 
assertion should not be declared safe. If REASON decides that moving this assertion 
is important it can try backward chaining rules on the if-then-else assertion to create a 
case analysis. In one of these cases it will assume that the indices are not equaL 
This will cause the assertion f -2 (the inequality of the indices) to come m, which will 
cause the possibility assertion f-3 to go out since its only support is f-2. But this, in 
turn, will out the unsafe assertion since it depended on f-3. Finally, the if-then-else 
part of the rule shown earlier will trigger, declaring the assertion to be safe. 

In the other half of the case analysis, if REASON assumes the indices to be 
equal the if-then-else part of the rule will trigger, leading to the conclusion that the 
assertion is not safe. It will still be true that it is possible for the indices to be equal, 
so f-i will stay in as will the not safe assertion derived from it In this case, 
REASON will have two justifications for believing that the assertion is not safe. 

As a further syntactic convenience, I have added an if-possible-then-else construct, 
which is invoked as follows: 
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( If-possible ( :f fact-1) 
then body-1 
else body-2) 


If 1 1 Tr-1 * s possible, then body-i is executed in a binding environment where :f is 
boiled to the possibility assertion for f-i. If fact-i is impossible (its negation is m), 
theil body-2 is executed in a binding environment in which :F is bound to the negation 


of F 


l. This is actually a macro for the following: 


( is-poss-ible fact-1) 

(rule ((:f f act-1)) 
body-1) 

(rule ((:f (not fact-1))) 
body-2) 


For 
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Section 11.3: Safe-from and Not Safe-from 

There is still a difficulty in the rules as stated. Whereas it is possible for a 
single rule to determine that an assertion is not safe by looking at a single side-effect 
assertion, it is not possible for it to determine that it is safe. It can only determine 
that the particular side-effect being examined doesn't affect the assertion. There 
might be other side-effects on this transition, however, which do affect it It is, 
therefore, necessary to be more specific in the notation, introducing a safe from 
assertion which states that the assertion is unaffected by a particular side-effect 
Similarly, the negation of such an assertion would state that the particular side-effect 
does affect the assertion in question. Thus if we had: 


F-l (Side-effect array-1 s-m s-out (Index array-1 index-1 object-2)) 
F-2 ((Index array-1 index-0 object-1) s-in) 

we could write: 


F-4 (Safe-from F-l F-2) 


The safe assertion originally used above can only be deduced if the old assertion is 
safe from every side-effect on this transition. To make its assumptions explicit, 
REASON first gathers up all the side-effects on the transition and explicitly records 
the assumption that these are all the side-effects. 


F-l (side-effects-on-transition s-1 s-2 ( ... )) 

Also a rule is created which triggers if any other side-effect on this transition is 
noticed; this rule will negate the assumption that all the side-effects have been 
considered, thus outing the safe assertion and forcing a re-evaluation of the safety of 
the assertion. Finally, a set of conjunctive goals is established to show that the 
assertion is safe from each side-effect on the transition. If these succeed, the 
old-assertion is asserted to be safe. The safe assertion is given a justification which 
points to each of the safe-from assertions gathered in the conjunctive goals, plus the 
assertion f-i above. This guarantees that if anything is changed (Le. if a new 
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side-effect is added, or if one is removed) a recalculation of the true dependencies will 
be conducted. 

An example of this use of safe-from assertions is the following "fast and dirty" 
rule 'or part side-effects which says that a part assertion of one object is independent 
of pmt side-effects to another object: 

(rule (( : f 1 (side-effect :object-l :s-in :s-out 

(:part-name-l :object-l :new-value))) 

(:f2 ((: part-name-2 :object-2 :old-va1ue) : s-in)) 

< :f 3 (( :object-type :object-l :type-l) :s-in)) 

(:f4 ((:object-type :object-2 :type-2) :s-in)) 

(:f5 (part :type-l :part-name-1)) 
l (:f6 (part :type-2 :part-name-2 ))) 

(cond 

! 

((equal :object-l :object-2)) 
j (t (assert '(safe-from :fl :f2) 

' (diff-obj-part-side-eff :fl :f2 :f3 :f4 :f5 :f6))))) 

! Notice that this is a fast and dirty rule, since even if object-i and object-2 are 
diffi rent object names, it is still possible for them to be anonymous objects which 
might be identical. The careful version of this same rule, makes this possibility 
explicit by adding the following: 

( If>ssible ( :g (id :object-l :object-2)) 

| then 

(cond 

((equal :part-name-l :part-name-2) 

(assert '(not (safe-from :fl :f2)) 

’(poss-id-part-effect :g :fl :f2 :f3 :f4 :f5 :f6))) 

(t (assert '(safe-from :f1 :f2) 

'(diff-obj-part-side-eff :fl :f2 :f3 :f4 :f5 :f6))))) 


For 
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Section 11.4: More Complicated Effects 

So far the analysis of side-effects has been quite simple considering only 
assertions about parts and indexed-parts. These are the most primitive notions in the 
system in the sense that they are not defined in terms of any other programming 
construct. However, as we saw in our description of programming objects, a host of 
more complex notions has been developed to allow programs to be thought of in more 
high level terms. 

The complex relations which are often used in describing programs are logical 
combination of assertions which ultimately depend on the part structure of the objects 
implementing the more abstract notion. For example, in hashing systems there is a 
notion of membership in the table which is always defined in terms of membership in 
one (or more) of the indexed-parts (buckets) of the table. Similarly, since buckets are 
frequently implemented as lists, membership of an object in the bucket reduces to 
whether the object is the first part or a member of the rest part of the list Thus, 

simple side-effects to the part structure of an object can result in side-effects to 

derived properties of the object For example, modifying a table to set one bucket to 
the empty-list will (potentially) delete several members of the table. The processes 
handling side-effects, therefore, must examine the way in which facts in the input 

situation of a transition depend on one another and use this as a guide to the 

transition analysis. Consider the following fragment from a hash-table-delete program: 
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Hash- 
Tab I e- 
DeIete 


Fragment of A Hash Table Delete Routine 


where the list-delete used here works by side-effect, changing cdr pointers so that 
after its completion, the list will contain exactly those members of its input list which 
do hot have the input key. Suppose that this fragment were part of a larger plan and 
that in some previous situation of this plan we had concluded that entry- 1 was a 
meiriber of the table since it was a member of bucket-i which is the bucket hashed to 
by it: key key-i. Finally, let us suppose that entry -1 has the same key as that input to 
the CJrrent plan fragment Obviously, REASON ought to conclude that entry- 1 is not 
a member of the table after the delete operation is performed; let us follow its 
reasoning process: 


it follows from the protocol outlined above that in any transition involving no 
side-effects, all assertions are safe. Thus, any assertion true at entrance to this 
fragment will cross the transitions for fetch-bucket, reaching associative-list-delete. Let 
us dll the input and output situations of associative-list-delete s-in and s-out 
respectively. We have the following facts: 
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S- IN 


f-l (Mpinhop t.able-1 entry-1) 

\ -y. ( kry Piit.ry-l koy-1) 

1-3 (hash table-1 key-1 index-1) 

1-3 ( bucket table-1 index-1 bucket-1) 
f-b (Member bucket-1 entry-1) 


buckct-1 



1-b (side-effect bucket-1 


5-OUT 



0 


r 

9 


(not (member bucket-1 entry-1))) 


Effect of Associative List Delete on Hash Table Member 

Notice that the side-effect f-6 makes the assertion f-s in s- in unsafe (by direct 
negation). We can also use the rules shown so far to determine that f-4 f -3 and f -2 
are safe from the side-effect f-6 ; since this is the only side-effect on this transition, 
these are safe to move across the transition 


The membership assertion f-i depends on f- 2 , f-3, f-4 and f-s since it was derived 
from these assertions using the relation-definition rule for hash-table membership. But 
f - 5 , one of these facts, is made unsafe by the side-effect on this transition. It would 
seem then that we should follow the justification from f-5 to f-i, concluding that since 
one of its supports has become unsafe, f-i should also be judged unsafe. It would 
correctly follow that there is no reason to believe that entry- 1 is still a member of the 
table after the side-effect, i.e. that the side-effect to f-5 has caused a derived 
side-effect to f-i. 

This suggests using the justifications to guide an analysis of derived side-effects. 
It is my feeling that an elegant extension to the TMS dependency system will make 
this possible (Doyle, McCallester, and Stallman have all suggested this idea in personal 
communications), however, REASON uses a different method, which is motivated by 
the fact that the logical connection between facts might not be represented explicitly. 
In the example above we assumed that we had deduced that entry -1 was a member of 
table -l, and thus we already had a justification recording what facts this assertion 
depended on. It was then a simple matter to see that the side-effect which deleted 
an entry from one of the table's buckets also effected the membership assertion. 


Dependency Directed Reasoning 







11.4 More Complicated Effects 219 


f owever, suppose that this membership assertion had not been deduced, but had 
^en told to us (as an output assertion of some other sub-segmenfs specs) or that 
been assumed. Then the only justification for the membership assertion would 
be a dependency on the spec clause or on the reason for making the assumption. 


(spec cliuiso or assumption reason) 


S - In 



Bucket-Delete 


F-Z 

(side-effect 

(Not (member bucket-1 entry-1))) 


Side-effect on Unexpanded Defined Relation 

Notice that in this circumstance, which is actually much more typical than that shown 
earlier, there is no set of justifications linking the membership assertion f-i to the 
a$ser|ion negated by the side-effect f -z. However, consider what would happen if f-i 
expanded into its definition. This would produce exactly the facts f-2, f-3, f-4 
^-5 which we saw in the earlier example. As these are asserted, they will 
ish the logical connection between f-i and f-5 that we saw earlier. 


were 

and 

estaH 


The key problem, therefore, is for REASON to identify those circumstances in 
which it is necessary to force this expansion of defined relations. Rules of the 
following form would at first glance seem sufficient. 


(Rule (( : f1 ((Member :table :entry) :s-in)) 

(:f2 (Side-effect :table :s-in :s-out 

(Not (member :bucket :er»try)))) 

( :f3 ((Object-type :bucket bucket) :s-in))) 

(assert (expand ((Member :table '.entry) :s-in)) 

(expand-for-transition-processing :fl :T2 :f3))) 



Rules like the one above could be created by analyzing the definition of the 
on involved yielding an expansion rule for each clause involved in the definition, 
ver, I have approached the problem somewhat differently. This is discussed in 
ext section. 
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Section 11.5: Determining What’s Affected 

As I mentioned earlier defined relations introduce a connection between assertions 
which must be analyzed in side-effect processing. For example, let us define list 
membership in the standard way: an object is a member of a list if it is either the first 
of the list or a member of the rest of the list. A side-effect changing the first of a 
list might change a membership relation. Similarly, in the above example, we saw 
the connection between bucket parts of a table and membership in the table. 

When presented with a relation-definition, REASON produces rules used in 
transition processing. 

Relation definitions have the form: 


(relation objl obj2 ..) <=> (compound-expression objl obj2 ... > 


where the compound expression is a combination formed from the logical connectives 
and, or, not, for-all, there- is, implies, i f - the n - else. The compound expression may also 
involve the use of reference expressions which, in effect, introduce new objects on the 

right hand side of the definition which are not mentioned in the left hand side. For 
example: 


(Member list object) 0> (Or (First List Object) 

(Member [Rest List] Object)) 

makes reference to the rest of the list, which is not an object mentioned on the left 
hand side. In an expanded form we might write this as: 


(Or (First List Object) 

(And (Rest List List-1) 

(Member List-1 Object))) 
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where list -1 is a new object introduced to resolve the reference expression. From this 
we cm extract two forms of information: One is a network of potential dependency 
assertions, linking assertions to those side-effects which might make them unsafe. The 
seconi form of information is a set of REASON rules which assert safe and unsafe 
assertions. For example, from the definition for list membership we can get the 
following potential dependency assertions: 

( potential-dependency (member :list : object-1) 

(first rlist :object-2)) 

(potential-dependency (member :list :object-l) 

(rest :list-l :1ist-2)) 

( potential-dependency (member Mist :object) 

(not (member : 1 ist-1 :object))) 

Potential dependency assertions are the information used to determine that there might 
be a logical connection between a fact and a side-effect These say that if (1) There 
is an assertion in the input situation which matches the first pattern and (2) There is 
a sido-effect on the transition which matches the second pattern, then it is possible 
that he assertion is rendered unsafe by the side-effect. Notice that in the case of 
dependencies on non-functional relations (such as member) the dependency is on the 
negat on of the relation. If functional relationships (such as part or indexed-part) 
assert ons are involved, a side-effect asserting a new value for the relation, such as 
(First List foo), implicitly negates any previous value of the property, such as 
(First List Bar); for these relations the dependency pattern is not negated. Also note 
that we have omitted the object-type information that goes with the assertions; 

however, since these assertions are used only to find things which might be affected, 

omittng the object-type information will simply allow some assertions to be considered 
even though they are not affected. This can do no harm, it can only make the 
systen overly cautious. 

The network of potential dependency assertions is completed by using a 
transi ivitv rule to reflect the fact that if f-i depends on f- 2 , which in turn depends 

on f-j, and if f-3 is made unsafe by a side-effect, then f-2 and, in turn, f-i also 

become suspect: 
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(rule ((:f (potentia!-dependency :a :b)) 

(:g (potential-dependency :b :c))) 

(assert (potential-dependency :a :c) 

(pd-trans :f :g))) 

The information in the potential dependency assertions is used by a rule which 
monitors transitions looking for facts which might be made unsafe by a side-effect If 
such situations are noticed, the rule asserts that the fact is possibly-unsafe. Any fact 
which is possibly-unsafe is expanded. 


(rule ((:f (potential-dependency :a :b)) 

(:g (side-effect .-object :s-in :s-out :b)) 

(:h (:a :s-in))) 

(Assert '(possible (not (safe-from :g :h))) 

'(pd :f :g :h))) 

(Rule ((:h (Possible (not (safe-from :f :g))))) 

(Assert '(Expand :g) '(pd-expand :h))) 

The rules for developing the potential dependencies are as follows: If the connective is 
and or or then build a potential dependency for each clause of the conjunction or 
disjunction. ( implies p o) is logically equivalent to (or (not p) q) and is handled 
accordingly. Similarly, if-then-else is built from implies. The quantified statements 
require a brief explanation. If we have 


F-10 (For-all :vars :p :q) 

then two kinds of side-effects could make F -10 become not true. One is a side-effect 
which causes some object which does not satisfy : q to satisfy :p, creating a counter 
example to the universal quantification. The other is a side-effect to an object which 
currently satisfies both :p and :q so as to make it no longer satisfy :q. Therefore, 
universally quantified statements potentially depend on both :p and :o. A similar 
argument holds for existential quantification. 
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so fa 




rwo points about these rules for determining potential dependency should be 
First, these rules only signal the possibility that an assertion is affected by a 
ffect; it is for other more thorough rules to explore whether or not the assertion 
ly is safe or not. This allows a many layered control structure in which one set 
les notices candidates for examination, and other sets of rules chose to examine 
candidates at a level of detail deemed appropriate. 

rhe second point to be made here, is that the potential dependency rules shown 
■ are actually of the "fast and dirty" variety. Remember that the swap example 
d that different local variable names might, in fact, name the identical object 
ly people rule out this possibility of "aliasing" to facilitate their analysis, 
ver, to be completely accurate one must examine all possibilities. 

rhe careful version of a rule for list membership, for example, is: 


(rule ((:f (side-effect :obj :s-in :s-out (first :obj :new-first))) 

( :g ((member :obj-2 -.old-first) :s*in))) 

( If-possible ( :h (id :obj :obj-2)) 

then (Assert '(possible (not (safe-from :f :g))) 

'(poss-or-se-careful :f :g :h)))) 

requires that the system have rules for determining whether objects are identical 
ot, and furthermore that it maintain this information rather carefully, 
nately, most procedures do not involve a large number of objects so this task is 
ble. There are several ways in which the system can deduce the non-identity of 
ts (we have already discussed ways in which it can determine identity). One rule 
it if an object is newly created in a situation which comes after a situation in 
a second object was known to exist then the two objects are not identical*. 


(rule ((:f (new :object-l :s-in :s-out :fact)) 

( :g (occurs-in :object-2 ( :fact-2 :s-other))) 
( :h (comes-before :s-other :s-out))) 

(assert '(not (id :object-l :object-2)) 

'(diff-date-of-birth :f :g :h))) 
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A second rule for non-identity uses the disjointness relation between types in the 
object-type hierarchy to infer that two objects have different types and are, therefore, 
distinct Finally, both of these are special cases of the general rule that if a property 
holds of one object but not of the other then those objects are distinct 

Once it has been determined that an assertion is possibly affected by a side-effect 
it remains to be determined whether the assertion is safe or unsafe. A second set of 
rules is developed from the relation-definitions, by going through the logical 
connectives used in the definitions. For example, a conjunction in which one conjunct 
has been side-effected can be deduced to be unsafe. However, a disjunction must be 
analyzed further. The following rules conduct this analysis for list membership: 


(rule ((:fl (possible (not (safe-from :f2 :f3)))) 

(:f2 (side-effect :11st :s-in :s-out (first : 1 ist :obj-l))) 

( :f 3 ((member :list :obj-2) : s - in)) 

(:f4 ((Rest :1ist :rest) : s-1n))) 

(if-possible (:f5 ((not (Member :rest :obj-2)) :s-in)) 
then (Assert '(Not (safe-from :f2 :f3)) 

'(dj-not-safe :fl :f2 :f3 :f4 :f5)) 
else (Assert '(safe-from :f2 :f3) 

'(dj-safe :f1 :f2 :f3 :f4 : f5)))) 

If it is possible that the old first element of the list occurred only in the first 
position, then it is possible that the side-effect of changing the first of the list would 
cause that element to cease to be a member of the list. Thus, a cautious strategy 
avoids moving this fact over the transition until more information is knowa If it is 
ever learned that the object was definitely a member of the rest of the list then the 
assertion will be declared safe by the second clause of the if-possible rule. In the 
mean time, this cautious strategy prevents any defaulting strategy of the first pass 
analysis from being too lax. 

Notice that side-effect rules such as the one above are triggered by the possibly 
unsafe assertion , rather than by the side-effect assertion directly. (The possibly unsafe 
assertions are created by the potential dependency rules). This allows other rules to 
decide which assertions should be worked on. In a later section we will see a set of 
rules which rule out possible unsafety, helping the system to avoid useless work. 
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Since we want to consider all side-effects which might arise, let us consider an 
example in which the above side-effect leads to a derived side-effect . Suppose that in 
addit on to the assertions above about list membership, we also had an assertion 
stating that the object deleted from the list was a member of some hash-table in the 



situation. Since we have concluded that the list membership assertion was not 
if it is possible that this list is a bucket of the hash-table we should conclude that 
ash-table membership assertion is unsafe as well To start this process, however, 
lust first state that there has been a side-effect to the list so that the potential 
ency rules may trigger. This is done by a simple rule which translates unsafe 
ions into side-effect assertions.: 


(Rule ((:f (Not (safe-from :f2 :f3))) 

(:f2 (Side-effect :obj :s-in :s-out : s e)) 

(:f3 ( : fact : in-sit))) 

(assert '(Side-effect :obj :s-in :s-out ((Not :fact) :s-in)) 

'(trans-se : f ))) 

The effect of this rule is that every time an assertion is determined to be unsafe, it is 
then treated as a side-effect itself, initiating a consideration of derived side-effects. In 
this case, this will lead to the triggering of the rule for hash table membership: 

(rule (( : f 1 (possible (not (safe-from :f 2 :f3)))) 

(:f2 (side-effect :list :s-in :sout (Not (Member :list :obj)))) 

(:f3 ((Member :table :object) :s-1n)) 

(:gl ((key :obj :key-I) :s-in)) 

(:g2 ((hash :table :key-l :index-l) :s-in))) 

(If-Possible ( :h ((bucket -.table :index-l :list) :s-in)) 
then (Assert '(not (safe-from :f2 :f3)) 

'(se-tab :f1 :f2 :f3 :gl :g2 :h)) 
else (Assert '(safe-from :f2 :f3) 

'(se-tab :f1 :f2 :f3 :gl :g2 :h)))) 



, the side-effect propagates through the various levels of definition. Notice that 
a definition involves reference expressions, these are handled somewhat specially, 
e side-effect is to a clause within the definition which has reference expressions 
; it, (as does the definition for membership in the list which implements a bucket of 
h- table), then these reference expressions are converted to patterns and moved 
Je the if-possible expression. However, if the side-effect challenges a reference 
ssion nested inside other reference expressions, then the outer references must also 
ated in the if-possible construct 
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There are still other logical connectives to consider in the building of side-effect 
rules. Universal quantification presents analytic problems similar to those of 
disjunction. Consider the definition of being an alist, a list, all of whose members are 
pairs whose left parts are atoms: 


(Object-type list Alist) 

<=> (for-all (:el) (member list :el) 

(object-type [left :e1] Atom)) 


As I mentioned above, two different kinds of side-effects can make an assertion of 
this form unsafe. A side-effect which entered a new element into the list might 
challenge such an assertion (if the key of the new object isn't an atom). Similarly, 
changing the key of one of the existing elements could undo the truth of the 
quantified statement if the new key is not an atom. Thus, a side-effect rule for 
universally quantified statements must trigger in either event and then examine 
whether to declare the statement unsafe. The following rules do this for the above 
definition: 


(rule ((:f1 (possible (not (safe-from :f2 :f3)))) 

(:f2 (side-effect :obj :$-in :s-out (key :obj :key-2))) 

( :f3 ((object-type :list alist) :s-out))) 

(if-possible (:f4 ((member :1ist :obj) :s-in)) 
then (assert '(not (safe-from :f2 :f3)) 

'(uq-n-safe-cautious :fl :f2 :f3 :f3)) 
else (assert '(safe-from :f2 :f3) 

' (uq-safe-1 :fl :f2 :f3 :f4)))) 

(rule ((:f1 (possible (not (safe-from :f2 :f3)))) 

( : f2 (Side-effect :obj :s-in :s-out (member :list :obj))) 

( :f3 ((object-type :1 1 st alist) :sin)) 

( :f4 ((key :obj :key) :s-in))) 

(if-possible (:f5 ((not (object-type :key atom)) :s-in)) 
then (Assert '(Not (safe-from :f2 :f3)) 

'(uq-not-safe-cautious :fl :f2 :f3 :f4 :f 5)) 
else (Assert '(safe-from :f2 :f3) 

'(uq-safe-2 :fl :f2 :f3 :f4 :f5)))) 

The above rules are examples of the "fan and dirty" type in that they do not 
attempt to check for the identity of anonymous objects. A second version of these 
rules (along the lines shown earlier for the "second pass" rules) does the extra 
checking. 
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Section 11.6: An Example 

'-et us now look at how REASON uses these rules to analyze a hash-table 
deletion routine which deletes all members of the table with a given key. One wants 
to pnve three things about this program: (1) The desired elements were deleted, (2) 
Nothing else was deleted, and (3) Nothing extra was added. Each of these is a 
unive sally quantified statements: 

(for-all (:entry) ((member table :entry) in-sit) 

(if ((key :entry key-1) in-sit) 
then (side-effect ((not (member table :entry)) out-sit)))) 

(for-all (:entry) ((member table :entry) in-sit) 

(if ((not (key :entry key-1)) in-sit) 
then ((member table tentry) out-sit))) 

(for-all ( :entry) ((member table :entry) out-sit) 

((member table :entry) in-sit)) 

To prove the first of these REASON assumes that there is an anonymous object 
entry- k which is a member of the table and whose key is the given key (in the input 
situation). It then attempts to show that the table has been modified so that this 
entry is not a member of the table in the output situation. The following is a 
comp ete plan diagram for the program with accompanying assertions which follow 
from the symbolic evaluation. 
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Plan Diagram for Hash Table Delete 


As I described above the membership assertion involving entry-a will pass through each 
of the first transitions, but will be stopped by the transition representing the action of 
bucket-store. The assertion will then be expanded into its definition: 

((Member Table-1 Entry-A) s-in) <=> ((key Entry-A Key-1) s-in) 

((hash Table-1 Key-A Index-A) s-in) 

((bucket Table-1 Index-1 bucket-1) s-in) 

((Member bucket-1 Entry-A) s-in) 

The support structure for the unsafe assertion associated with the membership assertion 
is now constructed. This structure makes the safety of the membership assertion depend 
on the safety of the bucket assertioa But since this assertion is unsafe, the membership 
assertion is also deduced to be unsafe. However, the assertion 
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((Member bucket-1 Entry-A) s-m) 


es move safely up to the list-delete routine whose specs say that it creates a new 
ck it which contains all entries in bucket-i except those whose key is key-i. entry-a, 
ver, is asserted to have key-i as its key; it is, therefore, not a member of bucket- 2 , 
utput of list-delete. We have: 


((Not (member bucket-2 entry-A)) s-6) 

e that this assertion is safe to cross the transition representing the bucket-store 
;ide^effect, as are the hash and key assertions. Thus in s-7, the output situation of 
jucKtt-sTORE we have: 


((Not (member bucket-2 entry-a)) s-7) 

((hash table-1 key-1 index-1) s-7) 

((key entry-a key-1) s-7) 

((bucket table-1 index-1 bucket-2) s-7) 

which the antecedent inference rule corresponding to the relation-definition for 
table membership infers that entry-a is not a member of the table. Since this 
mce depends directly on a side-effect at this transition it is also a side-effect 
hus have: 


(Side-effect table-1 s-in s-out 

((Not (member table-1 entry-1)) s-out)) 

i was the sub-goal needed to deduce the desired universally quantified statement 
e have shown that all entries with the given key are deleted. 


Now REASON has to show that nothing was deleted which should not have 
Again it creates an anonymous object entry-b assuming that entry-b is a member 
le table and that its key is not key-i. The facts propagate similarly to above; 
ver, when REASON tries to expand this assertion it discovers that it does not 
r the key of entry-b (we only know that its key is not key-i) and, therefore, that 
we also don't know the index this key hashes to or the bucket which is in that slot of 
the table. Anonymous objects are created to stand in for all of these. 
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({Member table-1 Entry-B) s-in) <=> ((key Entry-B Key-B) s-in) 

{(Hash table-1 Key-B Index-B) s-in) 

{(bucket table-1 Index-B Bucket-B) s-in) 

{{Member Bucket-B Entry-B) s-in) 

The transition processing becomes somewhat more complicated. We have the 
following assertions and side-effects involved: 


((bucket table-1 Index-B Bucket-B) s-in) 

(Side-effect table-1 s-in s-out 

((bucket table-1 index-1 bucket-2) s-out)) 

The source of the problem is that REASON does not know whether index- 1 and 
Index-B are equal or not since index-b is an anonymous object Therefore, REASON 
engages in a case analysis, splitting into two cases: (1) index-i equal to index-b and (2) 
index- i distinct from index-b. Each of these case gives the desired results rather 
directly. If the two indices are distinct then the bucket assertion above is safe. 
Similarly, all the other supporting assertions are safe, leading to the result that the 
membership assertion itself is safe; i.e, in this case, the membership of entry-b in the 
table is unaffected by the changing of the bucket since it is in a different bucket 

In the other case, index-i is equal to index-b and thus bucket-i is identical to 
bucket-b. An identification (see Chapter 4) of bucket-b to bucket-i is performed, leading 
to the conclusion that entry-b is a member of bucket-i in s-in and, therefore, by the 
specs of list-delete, entry-b is also a member of bucket -2 which is then stored into the 
table. As above, this leads to the conclusion that entry-b is a member of the table in 
the output situation. 
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Section 11.7: Pseudo Parallelism 

|As I have mentioned plan diagrams allow a weak form of parallelism. Although 
not at this time interested in the extra problems (and opportunities) presented by 
el execution, I have found this parallelism a convenient way of capturing some 
i|alities of sequential processes. For example, in representing the most general 
of the binary-tree-traversal plan fragment, we found parallelism allowed us to 
kent the many possible traversal orderings in a single plan diagram. 


However, parallelism presents special difficulties when side-effects are introduced 
he programming discipline. Consider the plan diagram for MacLisp's nreverse: 


CURRENT 


PREVIOUS 



NULL? 
YES I NO 


CDR 


X 


RPLRCD 




RECUR 

f 



DO-NON-NULL 


*1 


segmf 
Inde 
these 
there 


JOIN-LISTS 


NREVERSE 


Surface Viewpoint Plan Diagram for Nreverse 

Without a control-flow link ordering the execution of the rplacd and the cdr 
nts, there is no guarantee that one segment will execute before the other. 

there is no information at all in this diagram about the mutual ordering of 
two segments. Thus, it is necessary to regard them as executing in parallel and, 
ore, capable of destructive interference 
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The plan diagram formalism regards any data-flow as taking a finite amount of 
time. In fact, since data-flows might be implemented by a pathway of many segments 
as in a queue-and-process plan, the time involved might be considerable. Therefore, it is 
also possible for the rplacd to have a destructive interference with the data-flow to 

NREVERSE. 

It follows that the transition analysis which I have discussed so far is too simple, 
since it has been conducted under the unstated assumption that plan diagrams are 
interpreted in a strictly sequential manner. Under this assumption all data flows 
preserve all properties and the only transition analysis required is at the transitions 
representing segments with side-effects. This will now have to be generalized to take 
account of the extra complexity posed by the possibility of parallelism. 

This generalization is an absolute necessity for the plan based analysis used in the 
programmer's apprentice as a whole, since its approach is to develop a catalogue of 
programming cliche's. Many of these cliche's, however, are enumerators such as a 
trail i ng-pointer-enumeration, to which other consumer plans are attached. When viewed 
from this perspective, there is an inherent parallelism between the enumerator and 
consumer plans. In the case of nreverse, this parallelism involves side-effects which 
must be analyzed correctly. 

A transition is redefined to be a pair of situations which are (1) Connected by a 
data-flow or a control-flow link, or (2) The input and output situations of a segment 
In general, a fact which holds in the earlier situation of a transition can be moved to 
the later situation if (a) It is safe to move the fact across the transition in question 
and (b) There is no other transition which could execute during the same time as the 
one in question which would render the fact unsafe. To move a fact from one end of 
a data-flow link to the other, one must first inspect whether there is some segment 
which can execute in parallel with that data-flow and which has a side-effect which 
threatens the fact 

To make this inspection easier, before performing the symbolic evaluation of a 
plan diagram, REASON first analyzes the data- and control-flows, breaking the 
diagram up into separate paths. These paths can then be separated into sets of 
parallel paths. Two transitions one on each of two parallel paths can execute in 
parallel. Once this analysis of the plan diagram into parallel paths is completed, the 
transition analysis above can be generalized quite simply. Side-effect rules are now 
triggered by the combination of three types of facts (1) The existence of a side-effect, 
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(2) The existence of a fact in the earlier situation of a transition and (3) The 
possibility that the transition corresponding to the side-effect is on a path parallel to 
the one on which the transition occurs: 


(Rule (( :fl ( : f act :s-l)) 

(:f 2 (Transition :s-1 : s - 2 )) 

( •' f 3 (Onpath :path-l :s-l :s-2)) 

( '• f4 (side-effect :obj :s-3 :s-4 :new-fact)) 

(:f5 (Onpath :path-2 :s-3 :s-4)) 

( •f6 (Parallel :path-l :path-2))) 

appropriate transition processing 

•) 

The actual analysis of the plan diagram into paths is rather simple. It begins by 
identifying path joining segments and path splitting segments, Le. those segments at 
whi<^3 1 two flows (data or control) come together at a single segment and those at 
which two flows diverge from a single segment Segment execution can only begin 
when all the inputs are present; thus, when two data flows join at a segment a 
synchronization point is established. Similarly, since no output leaves a segment until 

all the outputs are ready, a synchronization point is established at segment output as 
welL 


Path Splitting Segment 



Path Joining Segment 
Path Joining and Splitting 
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When a path splitting segment is noticed, two new path names are created, one for 
each diverging flow. The splitting segment is declared to be the head of both of 
these paths and the paths are declared to be parallel Similarly, when a path joining 
segment is noticed it is declared to be the tail of both paths entering it, and these 
paths are declared parallel. A segment which is entered by only a single flow, or by 
several flows each of which originates at the same segment is declared to be on the 
same path as the segment from which the flows came. This last step, however, is 
made to depend on the absence of other entering flows, so that if new flows are 
added to the diagram, new paths will be recalculated. 

Several other rules are also involved in the calculation. For example: Two 
segments which are at the terminal end of conditional-control-flow links originating 
from the same segment are on separate but non parallel paths. A pair of paths is 
parallel if it consists of one path internal to each of two segments w’here the two 
enclosing segments are on parallel paths. 

Consider nreverse again; a bug exists if there is no control-flow ordering the 
execution of the rplaco and cor segments. In the path analysis, these two segments will 
be analyzed to be on parallel paths; this will lead to the conclusion that there might 
be destructive interference between the rplaco and the data flow to the cor. The 

side-effect rules conclude that it is possible that the flow does not preserve the rest 
property. 

However, this depends on the assumption that there are no further flow links 
ordering the two segments. If the programmer should intervene, adding a control-flow 
link to make the rplaco follow the execution of the cor, then this assumption will be 
violated and the paths incrementally recalculated. In the new calculation of paths the 
rplaco will not be on a path parallel to the data-flow to the cor. But then, one of the 
facts supporting the unsafe declaration will be out , ow/ing the unsafe assertion itself. 
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Chapter 12: Reducing Complexity in Side Effect Analysis 

n describing data-structures I defined a notion of structuresharing in a recursive- 
struciure. Much of the complexity in reasoning about side effects occurs in 
recur lively defined structures which share some substructure. Suppose that we know 
of ths existence of two lists, and one of these is side-effected; given what we have 
developed so far, we must consider the possibility that this side-effect will change 
some properties of the second list as well However, if we knew that the two 
structures were disjoint, then this possibility would be eliminated, reducing the 
comp exity considerably. [Burstall, 1972] introduces some techniques for reasoning 
about side-effects which use this notion of disjointness to advantage. I will extend 
that notion in this chapter. 

_et us examine in a bit more detail why this is true. The following is a side 
effect rule for list membership: 

(Rule !(:fl (side-effect :list-l :s-in :s-out (first : 1 ist-1 :obj-l))) 

( : f 2 ((Member :list-2 :obj-2) :s-in))) 

[If-possible ( : f 3 ((sublist :1is t-2 :1 i s t-1) :s-in)) 

then (assert (not (safe-from :fl :f2)) (list-mem :f1 :f2 :f3)) 
else (assert (safe-from :f1 :f2) (list-mem :f1 :f2 :f3)))) 


this rale is derived from the following definition: 

(Relation (Member List Object) 

(definition: (Member List Obj) 

<=> (Or (First List Obj) 

(There-is (:sub) (Sublist List :Sub) 

such-that (Member :Sub Obj))))) 

Suppose that we know that list-i and list -2 do not share any structure; we can 
determine quite simply that it is not possible for the side-effected list to be a sublist 
of th; other. This removes the need to conduct a thorough investigation as outlined 
in th< preceding sections. 
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I will present in this section a hierarchy of classification for side-effects, 
properties and the degree of sharing exhibited by recursive-structures. Given that we 
have seen how lists and trees can be defined as special kinds of recursive-structures, 
this classification will be applicable to most of the useful structures of LISP 
programming. The purpose of this classification is to use the level of sharing to limit 
the degree to which side-effects to one structure can effect properties of the other. 
Similarly, the classification of properties into levels isolates properties of a higher level 
from less powerful side-effects. 

Actually sharing is not as important as the lack of it: disjointness. I have 
identified three types of disjointness which have some utility. I have previously 
defined structure sharing as having a node in common. Structurally disjoint structures 
are those which do not share structure For lists this means that no sublist (the 
transitive closure of cor) of the two lists is shared. 

Often we will have non-recursive structures such as hash-tables whose parts are 
recursive structures. For such objects, we define structure sharing in the obvious way; 
namely two objects share structure if there is a part of the first and a part of the 
second which share structure. Thus, a hash-table and a list share structure if one of 
the table’s buckets shares structure with the list They are structurally disjoint if 
there is no bucket of the table which shares structure with the list 

The next type of sharing is termed value sharing. Recall that the nodes of a 
recursive-structure can have other parts (called valued besides those which represent 
the immediate-children of the node A list is a recursive-structure which has a value 
at each node called the first. Similarly some types of binary-trees have a value at 
each node. (See Chapter 10 for a review of these notions). When there is an object 
which is a value of two recursive structures, we say that there is value sharing ; 
conversely, if there is no such object we say that the structures are value disjoint. 
Notice that if two objects share structure, they then must share values; since they 
have at least one node in common, the value of this node is a value of the two 
structures; therefore they share values. It follows that if two structures are value 
disjoint , they are also structurally disjoint. 
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Two objects are totally disjoint if (1) The objects are both structurally and value 
disjoint and (2) All objects pointed to by each node are totally disjoint For example, 
two ists are totally disjoint if they share no sublists, if the members of the lists are 
distinct, and if as well the members of the first list are totally disjoint from the 
mempers of the second. 

It follows that if two recursive-structures are totally disjoint, then side-effects to 
the one can not effect the other. Unfortunately, although total disjointness is not 
completely rare, it is not the most common event either. In particular, lists frequently 
have common members such as atoms, and are, therefore, not totally disjoint 
However, structure sharing is also reasonably rare. The sharing of list structure 
presents enormous opportunities for powerful interactions and thus for bugs; therefore, 
most programmers avoid sharing except in those cases where the power is actually 
desired. Most side-effects have very limited scope as long as there is no structure 
shari ig. 

To begin, let us classify side-effects in a manner similar to that used for 
structure-sharing. We call side-effects strictly structural if they only affect the 
imna idiate-children property of some node of the structure, rplacd is the simplest such 
side-effect, although list-insert and list-delete, nreverse, sort, nconc and various other 
built-in functions of MacLisp also are strictiy-structural side-effects. Notice that a 
stric ly structural side-effect to one structure will not affect any property of another 
obje 't which is structurally disjoint from the first 

We may also identify strictly value side-effects such as rplaca which only change 
value parts of a recursive-structure. If two structures are structurally disjoint, then a 
strictly value side-effect to one will not affect properties of the other. A structural 
side effect is one which consists only of strictly structural and strictly value 
side-effects. A sort program which works by changing both car and cdr pointers in a 
list is an example of a structural side-effect Again if two objects are structurally 
disjoint, a structural side-effect to one will not change any property of the second. 

Finally, an indirect side effect is one which only changes properties of values of a 
recursive-structure. For example, a marking graph traversal procedure which sets the 
mark property of the value of each node is such an indirect side-effect procedure. If 
two objects are value disjoint, then indirect side-effects to one will leave properties of 
the other unchanged. 
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We say a structure is isolated if it shares structure with no other objects. We 
may divide this into the types used above, referring to structural, value, and total 
isolation. Most routines which build new structures such as append, or list create 
structurally isolated objects. This is important, since a structurally isolated object is 
relatively safe to side-effect; often programs will create a copy of an object and 

side-effect the copy as a means of guaranteeing that unwanted interactions do not 

result. 

Finally we come to a classification of properties. We can notice that some 
properties such as sublist or length only depend on the recursive structure of the 

object, and not on the values at each node. We call these strictly structural properties. 
More commonly, properties such as memo, depend both on the recursive structure and 
on the identity of the various values present at each node, but not on any property or 
sub-structure of these values; these are called value dependent properties. Finally, 

there are properties which depend both on the structure and on mutable properties of 
the objects present at each node, member (as opposed to memo), for example, depends on 
the structure of the list as well as on the structure of the objects pointed to by the 
list; if the list (a b c) is a member of the list l-i then the LISP invocation: 


(Member 1 (A B C) L-l) 

will return a non-nil answer, namely the list (a b c), which is a member of l-i. If this 
list is then RPLACAd so that its first element is x, then (member '(a b c) l-i) will return 
nil. Let us call such a property a value indirect property. 

A side-effect at one level can not effect a property of a lower leveL For 
example, a value side effect cannot affect a strictly structural property. An indirect 
side-effect cannot affect a structural property. 

These observations can be summarized by several simple rules of the following 

form: 
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will 

and 


(rule (( : f 1 (Side-effect :obj-l :s-in :s-out :se)) 

(:f2 (Structural-Side-Effeet :se)) 

( : f 3 ( Structurally-disjoint :obj-l :obj-2)) 

( : f4 (( : fact :obj-2) :s-m))) 

(Assert (Safe-from !:f1 !;f4) 

(Structure-disjoint :fl :f2 :f3 :f4))) 

(rule ((:f1 (Side-effect :obj-l :s-in :s-out :se)) 

(:f2 (Structural-Side-Effect :se)) 

( :f3 (Structurally-isolated :obj-2)) 

( :f4 ((:f act :obj-2 ) : s-in))) 

(Assert (Safe-from !:f1 !:f4) 

(Structure-isolation :fl :f2 :f3 : f4 ))) 

Notice that since these rules assert that a particular property is safe, they 
remcjve the need to engage in the more complicated analysis shown in the last chapter. 
A kirge percentage of side effects have very limited range of effect precisely because 
there is a strong limit on structure sharing. Most of the time one of the above rules 
fire and REASON'S work will be done. In some rare cases, the more complex 
thorough analysis will be required. 


This approach requires a classification of side effects into the various levels and a 
simil ir classification of properties. Relation-definitions provide the basis for these 
fications. To decide whether a property is structural one need only determine 
ler it depends on the node property of the object, given that the object can be 
viewed as a recursive-structure. Similarly, if the property depends on any value 
er of a node it is a value property. If it depends on properties of the value 


class., 

whetn 


poinj 


objects it is an indirect property. For example, consider the member relation for lists: 


Sincd 
a van 


is 
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(Member List Object) <=> (Or (first List Object) 

(Member [rest list] Object)) 

the property depends on first which is the value pointer for lists, the property is 
le property. Also since it involves a recursive definition involving the rest (which 
immediate-child pointer for lists) it is a structural property, image-in in a alist 
ndirect property as showm by its definition: 
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(Image-m Alist Key Value) 

<=> (There-is (:e1) (Member Alist :el) 

such-that (And (Key :e1 Key)(Va1ue :el Value))) 

Since this definition depends on member which is both a structural and value property, 
image-in is also a structural and value property. However, in addition it depends on 
the key and value parts of members, which are values; therefore, it is an indirect 
property. Side-effects may be categorized using a similar analysis of defined relations. 
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Chapter 13: Reasoning About Program Modifications 

In the previous chapters I have shown how REASON analyzes a program, 
maintaining an explicit representation of all logical dependencies. Although such an 
explicit representation is costly in terms of space consumption, I will show in this 
chap er how that cost is repaid during the process of program modification. It cannot 
be overemphasized that this concern has been the driving force behind my design 
decis ons. The price of software maintenance is the most rapidly escalating part of 
comf uter costs and the one with the least likelihood of decreasing. An expensive tool 
which effects a ten percent reduction in software costs would repay its cost quite 
many fold. 

When REASON has analyzed a program it has a very rich knowledge structure 
annotating the program text This structure includes a complete record of the proof 
of all pre-requisite and achieve goals, purpose links summarizing the inter-relationship 
between the spec clauses of the sub-segments and the main segment, links to 
implementation methods, defined relations and other knowledge about the data-objects 
of the program, and finally a recognition map connecting fragments of the program to 
the s tandard plans of the library. Such standard plans, in turn, are organized into 
specialization hierarchies in which, for example, list-enumeration is regarded as a 
specialization of the enumeration plan for general recursive-structures. 

When a program modification is proposed, REASON uses this rich knowledge 
structure to discover how far the effect of the proposed modification will propagate. 
Typically, there is some decomposition of the program in which the change has effect 
only within a particular segment's boundaries, leaving unchanged most of the logical 
struc :ure outside. For example, if the method of representing a set is changed from 
lists to arrays, then only the enumeration part of the program will be modified. By 
looki lg at the temporal viewpoint of the program we can regard the enumeration as a 
separate segment which produces a temporal-collection of the members of the set. This 
is trie in both the new and the old versions of the program. Thus, we know that the 
rest of the program (the part outside the enumeration) is not affected. 

The goal in analyzing a program modification is to be able to use the logical 
analysis of the old program to help understand the new program. As the programmer 
edits the old version, REASON attempts to follow the chains of dependencies to see 
what requirements of the old structure are no longer met If there are no such 
broken chains, then the modification is merely an addition of some new behavior 
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which can be analyzed by the mechanisms of the previous chapters. We will now 
look at how REASON determines what is affected. 

Most changes are relatively straightforward to analyze. For example, consider 
what must be done if a new expect clause is added to a segment First, the 
dependencies linking the expect clauses to the segment's applicable assertion must be 
rebuilt to include the new expect Then a proof of the new expect clause must be 
undertaken. If this succeeds, the segment will be declared applicable and no 
interaction with the user is required. If not, the applicable assertion for the segment 
will be out. 

The Truth Maintenance System can be requested to signal every time a particular 
fact changes status from in to out or vice versa. As REASON evaluates a plan 
diagram it makes such requests for every expect clause of a sub-segment and every 
assert clause of the main segment. Also such requests are made for the applicable 
assertions for each sub-segment and for the main segment Thus, when analyzing the 
effect of adding a new expect, REASON is first signalled that the sub-segment is no 
longer applicable. If the proof of the new expect clause succeeds, TMS signals that 
the status of the applicable assertion is now in Thus, REASON knows that 
everything is alright. If not, REASON reports that the segment is no longer 
applicable. However, all segments which depend on the modified segment will also 
become inapplicable; REASON collects these signals as well What to do with this 
information is the province of discourse expertise not yet present in the apprentice 
system. 

Removing an assert from a sub-segment presents a similar problem, although 
there is a new opportunity. Since REASON has already built purpose links, it is a 
simple matter for it to consult these before doing anything else. The purpose links 
tell REASON that the assert provides support for various sub-segment expect clauses 
and main segment assert clauses. Each of these is examined to see if they have other 
support which is independent of the clause being removed. If each such clause has 
independent support then the change has no effect; REASON tells the user that 
everything is in order. Otherwise, it issues a warning, saying which dependent 
segments are affected. If more information is desired, REASON follows through the 
actual justifications to build a trace of the broken proof. 
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I In the case where one clause is deleted and another is asserted, REASON waits 
until both actions have been performed before checking to see which applicable 
assertions have changed status. Otherwise it handies matters as above. 

When a data-flow link is changed, the assignment of objects to the segment’s 
inpijt ports to must be updated; those expect clauses which mentioned the affected 
port must be recreated with the correct objects substituted in. The justifications 
linking expect clauses to the segment's applicable assertion must then be rebuilt 
REASON then proceeds as in the case where an expect clause is changed. Notice 
that in all these cases when a part of the plan diagram is removed, the TMS outs all 
goals and conclusions which followed from the oute d statement 

When a relation of an object-type is redefined, similar effects take place. The 
rulefe corresponding to the relation definition not only make a deduction, but as with 
everything else in REASON, they provide a justification for the deduction. In the 
case of defined relations, the justification points to the assertion in which the 
relation-definition is stated. Thus, if the relation is changed, the old definition goes 
out < nd facts following from the definition also lose support 

More commonly, however, the programmer will not change a relation-definition, 
but will rather create a new object-type in which a different definition appears. If an 
object of the old object-type was deduced to have a particular property, then the 
justification for this will point to the most specific object-type in which the relation is 
defied. For example, the membership relation for alists is defined at the level of 
list}; the justification, therefore, points to the assertion stating that the object's type 
is l ijs t and not to the assertion stating that it is a alist. In contrast, the image relation 
(x is the image of y in the alist l-i if there is a pair whose left is x and whose right is 
y aijid that pair is a member of l-i) is defined at the level of alist; any deduction 
arisijrg from the image relation would depend on the assertion stating that the object is 
an A. ist. Thus, if the programmer changes the type of an object, all deductions 
whi<j:h depend on its having an object-type which it no longer holds will lose their 
support and go out. However, rules corresponding to the definitions of new relations 
corresponding to the new type might trigger, bringing in new facts. Finally, if the 
objejc-t is changed from one sub-type to another, it is possible that no important 
relation is defined at the more specific level and, therefore, nothing significant will 
happen. 
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In general, then, the pattern of reasoning at this level is quite clear. A plan 
editing program is instructed by the user to add, delete, or change some feature of a 
plan diagram or some part of an object descriptioa This action may cause some facts 
to change status from in to out or vice versa. If an applicable assertion for either a 
sub-segment or the main segment winds up being out after all effects have been 
propagated by the TMS, then REASON warns the programmer that an error has been 
introduced. 
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Section 13.1: Updating The Recognition Map 

When the apprentice first analyzes a program, it builds a recognition map 
ining how the program uses standard library plan fragments to achieve its goals, 
ogram modification will typically force the system to rebuild this map to reflect 
lew situation. Fortunately, simple modifications to program structure do not 
|t the recognition map in a drastic manner. For example, consider the following 
am: 


(def u 




Accuiru.il ate-Salary (Lis t-of-Employees ) 
(do ((1 List-of-Employees (cdr 1)) 
(Sum 0)) 

((Null L) Sum) 

(Setq Sum (+ Sum (Caar 1))))) 


This 

each 

folio 


ws: 


is a simple, unfiltered summation program. The list is a list of records, where 
record has the salary in the first position of the record. This is diagrammed as 


Unfiltered Summation Program 
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Let us consider various simple modifications which might be made to this program. 
Suppose, for example, that we put in a test so that we summed only the bi-weekly 
employees: 


(defun Accumulate-Salary (List-of-Employees) 

(do ((1 List-of-Employees (edr 1)) 

(Sum 0)) 

((Null L) Sum) 

(cond ((eq (cadar 1) ’bi-weekly) 

(Setq Sum (+ Sum (Caar 1))))))) 

where the second field of each record is the employee-type. Of course, the effect of 
this change is to filter the inputs to the summation segment The recognition proposer 
would suggest that the recognition of the summation segment is still correct and that the 
recognition of the list-enumerator is still correct (The recognition proposer [Rich, 1977] 
is outside the scope of this thesis). However, the temporal-collection input to the 
summation segment is now changed; the plan recognizer suggests that the new segment is 
a filter segment interposed between the enumerator and the summation routine. 
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Filtered Summation Plan 
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the recognition of two parts of the plan remains the same; only the filter 
n and the temporal-collection data-flows change at alL We can easily change 
nderstanding of the overall effect of the plan to reflect the addition of the filter 

by re-evaluating what collection of objects flow into the summation segment in 
lew plan. 


The basis for this separation is Water’s [Waters, 77] observation that recursive 
tins (including loops) can be broken up into a temporal decomposition by 
< tion of the pattern of data- and control-flow links. Thus, when a recursive 
un is modified, the system checks to see whether the clues used previously in 
ag the segmentation are still in. If so, it only tries to form segments for the 
Jode. Although, my system and Waters' are not yet interfaced into a unified 
ntice system, the discipline of explicit recording of ail important control 
ijiation can serve to make the interface a matter of less complexity than would 
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otherwise result. 

Let us consider another simple example showing how these techniques can be 
applied. Suppose that we had a program in which the data was stored as a list and 
that for some reason the program was modified to store the data in a binary-tree with 
a value at each node. The two programs are: 


(defun list-version (list) 

(do ((1 list (cdr)) 

(sum 0)) 

((null 1)) 

(cond ((eq (type-field (car 1)) 'biweekly) 

(setq sum (plus sum (salary-field (car 1)))))))) 

(defun tree-version (tree) 

(tree-vers ion-1 tree 0)) 

(defun tree-version-1 (tree sum) 

(cond ((eq (type-field tree) 'bi-weekly) 

(setq sum (plus sum (salary-field tree))))) 

(cond ((non-terminal tree) 

(setq sum 

(tree-version-1 (left tree) 

(tree-version-1 (right tree) sum))))) 

Sum) 


The second program can be analyzed as a composition of a tree-traversal, a filter, and a 
sequential-summation plan. Similarly, the first program can be separated into a 
list-enumeration and the same filter and sequential-summation plaa In making this coding 
change many surface details change, however, much of the deep structure of the 
program remains constant. As the apprentice analyzes the modification, it will have 
to rebuild the recognition mapping since some of the details of the recognition have 
changed. However, those details which don't change are represented as facts in the 
data base which stay in throughout the whole process. Thus, those deductions which 
are based on facts of the analysis which are not changed between the two versions 
stay in themselves and do not require any further deductive effort 

Let us look again at an example shown at the beginning of this thesis in which a 
hash-table is changed from a linked-list representation for the buckets to a rehashing 
scheme in which the cells of the array form the data structure to be searched We 
can easily see that both the list and the set-of-cells form an acyclic recursive structure 
of node-degree 1. We call such structures linear structures and observe that arrays and 
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shiglp paths through a tree are also linear structures. The plan library contains a 
hierarchy of plans for traversal of recursive-structures. The most general of which is= 



RECURSIVE- 

STRUCTURE- 

TRAVERSAL 


For incar-structures there is another more specialized plan which replaces the plan for 
enumerating the immediate-children by the more simple plan immediate child which 
fetches the unique immediate child of the current node. Thus, we get: 
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Linear 

Structure 



Enumerator Plan for Linear Structures 


Notice that this plan is merely a generator of successive sub-structures. In fact, it 
includes in its output the terminal element of the linear-structure which in most case 
(such as list-traversal) is not useful. More specialized versions of the 
linear-enumeration plan filter out the terminal. We are here concerned with a 
particular type of linear-structure, those with a value set of size 1 (Le. we want there 
to be a unique first value of each sub-structure). Most often we want to augment the 
specialized linear-enumerator with an operation to fetch the first value of the 
sub-structure. 
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Enumerator of Values of A Linear Structure 


plan can be specialized in many ways depending on the nature of the 
-structure. However, the specialization is always concerned with the 
entation of the linear-structure; i.e. with the particular means of fetching the 
diate-child and the particular means of fetching the first item of the 
ructure enumerated. In the two cases we are considering these details are quite 
ent. In the case of LISP lists, the immediate-child operator is cor and the first 
tor is car. 


powever, in the case of the rehashing scheme, things are a bit more complicated, 
sub-structures being enumerated are represented by a triple consisting of an 
an initial-index and a current-index. The next sub-structure is the object 

mented by the triple consisting of the same array and initial-index but with a 
Icurrent-index which is the rehash of the old current-index. Special provision is 
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made for representing the terminal sub-structure. For example, the rehash of the last 

index in the sequence can be a negative number; a triple with a negative current-index 

is defined to implement a terminal. The first item of any sub-structure is the item of 
the array indexed by the current-index. 

Thus, the above diagram can be further specialized for these two designs, 
replacing the more abstract first and immediate-child by car and cdr in one case and by 
array-fetch and rehash in the other. Similarly, the terminal-test in the two programs 
must be different since terminals in the two designs are represented differently. 

Notice that in the plan which uses rehash we use triples of objects to represent the 
sub-structures flowing between the subsegments. These triples are seen in the surface 
plan as separate data-flows involving the array, the initial-index, and the 

current-index. Higher level recognition procedures must group these three flows into a 
single virtual flow. 

This analysis lets us see where the modifications need to be made to effect the 
change in representation. For one thing, since the output of either of these more 
specialized enumerators is the same temporal-collection of values, we know that the 
consumer parts of the plan do not need to change. Thus, the lookup program in either 
version would involve one or the other specialized version of the above plan coupled to 
the following standard search plan fragment. 
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The key observation, however, is that the search plan can be seen to have no 
dependencies linking it to the design choice of the data-structure traversed by the 
ENUMti'ATOR. Indeed, only the terminal-test, first and immediate-child sub-segments of the 
enumciation plan depend on the design choice. When the programmer proposes to 
chart, :e the representation of the bucket from lists to a different type of 
linea -structure, the apprentice, can immediately determine the extent of the effects. 
The entire search part of the plan is safe and the only part of the enumeration which is 
affec ed is the first and rest parts which in the current version are the car and cdr 
segments, and the terminal-test which in the current version is the test null?. Based on 

these observations, the apprentice can describe in high-level terms what segments need 
chart] ;ing. 

In a more advanced version of the apprentice I expect there to be at least 
enough synthesis expertise to chose the correct specialization of linear-enumeration for 
traveling the rehashed-cells data-structure. The apprentice could use this newly 
seledted plan to inform the programmer how to change his program to conform to the 
new design. In any event, the ability to decompose the program into both temporal 
and surface viewpoints allows the apprentice to treat the above modifications as 
incremental just as would any reasonably skilled programmer. 
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Chapter 14: Conclusions 
Section 14.1: Good Decisions 


REASON'S design deviates from that of standard verification systems such as 
[Igarashi, et. al, 1973] in many ways. REASON is intended to be a part of an 
interactive programmer's apprentice system. It must function in a number of different 
contexts including interactive design, plan modification, and verification and it must 
service the needs of different communities of programmers using a variety of 
languages. These requirements led to several novel design decisions. 

In building the apprentice, it seemed essential that the system not be primarily 
concerned with the actual program text The primitives of a programming language 
are too low level to worry about during the early (and probably later) stages of 
design. Rich and I concluded that the system's formalism should be quite simple, 
consisting of program segments connected by control and data flow; these seemed to 
be the abstract notions which programming language primitives are intended to 
achieve. Also we thought that this formalism would be a convenient one in which to 
capture the teleological notions which constitute a plan 

The plan diagram formalism has, so far, done what it was intended to do. 
However there are some concepts which it can't handle. The formalism has no place 
for a procedure which, like an interpreter, manipulates the representation of another 
procedure, converting list structure into new data and control flow links. The notions 
of data and control pathways takes us almost to this goal, but more work needs to be 
done. Similarly, we currently have no way of describing interrupts or synchronization 
primitives. However, these were beyond the scope of our original goals; indeed, the 

kinds of programs which we wished to attack are simply and conveniently described 
by plan diagrams. 

A second novel design choice was to use a symbolic interpreter rather than a 
verification condition generator. The apprentice is intended to help a programmer 
design systems; this is a somewhat chaotic process in which a programmer might 
change his design frequently, moving segments, changing data flows, and adding in 
new segments to perform tasks which had been overlooked. To do this effectively, 
the programmer will need to have "snapshots" of the computation, so that he can ask 
whether a property holds at a particular point of the computation. REASON’S use of 
situations satisfies this need while adding yet another advantage. The deductive 
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ratus in REASON is completely integrated with the symbolic interpreter, allowing 
lification and partial deductions to be made as the interpretation of the plan 
?eds. 

A third unusual feature of my approach is that many low level language features 
y do not appear in REASON'S plan diagram formalism. Assignment to variables 
yarded as a means of implementing a data flow; while loops, etc. are all captured 
jcursion. I have grown to find this means of expressing a program quite natural 
simple and think that a front end for the system could be engineered to make 
diagrams a very natural vehicle for communication between the apprentice and 
irogrammer. 

One future development would be to use a graphics system to allow the 
ammer and the apprentice to communicate pictorially; the system would generate 
issertions of a plan diagram internally. The system would be able to display 
ard library plans, modifying and specifying them on command from the 
ammer. Systems could be designed by cutting and pasting pictorial plan diagrams 
tv screen. This would require the programmer to learn the vocabulary of the 
library, but I think this would be advantageous. The plan library gives names to 
tandard patterns of programming; if programmers began to think in terms of such 
ns, their task would be conceptually simpler. Search , accumulation, tree traversal , 
ire all more powerful conceptual terms than are while, do, etc. 

Another unique feature of the programmer's apprentice project has been our 


emphasis on plan recognition and the development of a plan library. Much of this 
work is being done in a separate thesis by Rich [Rich, 1977,78], yet its influence on 
REASON has been considerable. My concern with the temporal viewpoint and the 
reasoaing needed to support it is motivated by the needs of the plan library. This 
development has helped us develop a natural and powerful vocabulary for describing 
programs. Even if the rest of the project never reached fruition, the vocabulary itself 




great value and might form the basis for introductory programming classes. A 
it who learned to think in terms of standard plans, would probably have a much 
time mastering the basic skills of program design. 
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Turning now to my work on the reasoning system there are several decisions 
which I feel were positive. The use of Doyle's TMS [Doyle, 1978] as an integrating 
mechanism is well justified. The decision to place a great deal of emphasis on defined 
relations, allowing the user to state these declaratwely is another idea which seems 
worth the extra effort of having the system translate these declarations into various 
kinds of procedures. The work I have begun on reducing the complexity of side 
effect analysis seems a quite promising outgrowth of the general approach of 
integrating the reasoning system with a knowledge base and an epistemology of 
programming concepts. 

The main advance I feel that has been made in the current version of REASON 
is the task agenda protocol suggested by Doyle [Doyle, 1978b]. Although I have not 
yet fully developed the choice making protocols of the system, I believe that this 
offers the only route for building a system with evolving capabilities. Hopefully, 
future research will provide some insights into how to use this power to advantage. 
Finally, I think the initial work on modification reported here is moving in the correct 
direction. The use of temporal viewpoint plans to guide the system during 
modification sessions is a promising idea. 

Although the current version of the system is still being implemented, I did 
succeed in getting the first version to do some fairly involved proofs. In the scenario 
of this thesis the programmer designs an associative retrieval system along the lines of 
Conniver's data base. The first version of REASON successfully completed proofs of 
all the routines used in this data base, including the fast intersect routine, the indexer, 
and the pattern matcher. In addition, it recorded the dependencies produced during 
these proofs and summarized them into purpose links. It was not overly fast, 
however, and it needed most of the 256K available on our PDP-10 to complete the 
longest of these proofs. Although this earlier system had some success, it was not the 
system I wanted. The newer system combined with the MIT LISP machine hardware 
will probably be a far more useful machine. 
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Section 14.2: Problems 

I had hoped to implement more of the new system by now; yet each 
iinpli mentation stands on the shoulders of its predecessor. My experiences in 
imp ('meriting the earlier version of the system are worth mentioning. Originally I was 
prim irily concerned with the efficiency of the system and, therefore, rejected the 
already existing general purpose problem solving language in favor of building 
mechanisms carefully tailored to the special needs of program analysis. As a result I 
spent a considerable amount of intellectual effort on issues at too low a leveL As 
time passed, it became increasingly obvious that I was re-inventing the wheel 

One particularly painful aspect of this problem was the use of an unduly 
complicated context system (see [Rich & Shrobe, 1976]). REASON builds a situation 
tree representing the temporal behavior of the program; since it had to engage in 
hypothetical reasoning as well, I implemented an extension of the context mechanism 
of Csnniver [McDermott, 1972] which allowed two dimensions of context This was 
unfoi tunate; the mechanism was awkward and caused quite a few obscure bugs. 
Second, and far more significantly, the context mechanism is inappropriate for my 
purposes. However, since I was taking an incremental approach to the 
implementation, I didn't realize this until late in the first implementation at which 
point I was forced to stick with what I had. 

There are two circumstance in which the context mechanism seems unusable. 
The irst of these is plan modification; when a programmer modifies a plan by adding 
or deleting a segment or by changing a data or control flow link the succession of 
situt lions is changed. In such a circumstance, the context layers must be reorganized, 
often in ways which re precluded by artifacts of the context mechanism. Similarly, 
transition analysis is made cumbersome by the context mechanism which automatically 
move; facts forward. Some other process must intervene, erasing the fact in the 
context layer at which it ceases to be true. One can only begin to appreciate the 
hair; timing problems this can cause; to fully appreciate it, you should code up such 
a sys em and attempt to develop it Finally, there was a representational problem; in 
order to give a justification for a fact in a particular context it was necessary to have 
a name for the context To understand this name, the system had to have a map of 
which names come after which others. The justifications in the old system, therefore, 
were based on the situation tag representation while the reasoning system used 

conte (ts. The use of situation tags, TMS, and explicit control assertions is a far 
easiei^ discipline to live with. 
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The current system, however, has some irksome problems also. One of these is 
that it appears to be even more space consuming than the first implementation. 
W ithin the next few years the hardware revolution will make this concern irrelevant^ 
in the mean time, however, experimentation is difficult. A more serious worry is that 
the current sjstems mechanisms for side effect analysis, although correct, are not as 
natural as I would like. The truth maintenance system ought to be able to use its 
justifications to determine which facts ould move across a transition. McCallester 
and Doyle (private communication) have both suggested ideas for this kind of a 
process, but these have not been incorporated into the current desiga 

There are still important forms of reasoning which are outside of REASON'S 
scope. Primary among these is reasoning about termination and the closely related 
concern of time complexity. Techniques described later in the literature review such 
as "ghost variables" might be quite easily integrated into the current system, but I 
have not yet examined this idea thoroughly. Reasoning about space consumption is 
another issue which I have not yet addressed at alL Finally, many of the powerful 
heuristic techniques for inductive proofs used in some other systems 
[Boyer & Moore, 1977] have not yet been integrated into REASON. 
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Section 14.3: Future Directions 

I see this work growing in two directions at once. As I indicated in the 

introduction, my work can be viewed as a technical stepping stone for future work on 
self onscious systems such as that proposed in [Doyle, 1978b]. A next step in that 
direction is to build an interpreter for plan diagrams. This is, in principle, quite 
sirno e to do; it can follow the general pattern of the symbolic interpreter of this 

thesis. An interesting exploration would be to implement the symbolic interpreter as a 

plan diagram for the actual interpreter. Somewhat short of such fanciful exploration 
is tc begin to develop proof strategies as plan diagrams which are executed by the 
interpreter. This will allow proof steps to be parts of more macroscopic actions within 
whici they play well defined roles. These roles can then be categorized and used as 
the basis of both general and domain specific strategies. [Doyle, 1978b] discusses these 
ideas more fully. 

REASON seems to have quite a bit of room for development within the 

apprentice system as well. First of all, there are numerous tasks described in this 
thesi; such as modification, and recognition which are not yet integrated into the 
system. More interesting, however, are some avenues of exploration which we have 
not yet developed. One of these is the use of the reasoning system in more 
unconstrained recognition scenarios than I have presented here. 

I would like the apprentice to analyze 4 or 5 pages of related LISP functions 
with almost no human intervention. Such a task would involve sophisticated problem 
solving strategies drawing on the powers of the reasoning system. In particular, it 
seen5 that this kind of recognition involves a certain amount of design expertise. One 
organization of such a system would have a heuristic recognition component use lower 
level clues to guess what high level design underlies the code. This design would then 
be elaborated by a program synthesis module (now being worked on by Rich 
[Rid , 1978]) working cooperatively with the reasoning system. 

The next level task I would like to work on is the development of new expertise 
within the apprentice system. Currently, the system relies on a body of programming 
knowledge. As we now envision program synthesis, the apprentice can build a 
program when it knows plans appropriate for the synthesis task. This can go a long 
way if the knowledge base is extensive and sophisticated. However, introspection 
suggests that there is more to programming than just pasting together what one 
already knows. A direction of research which seems quite promising is to use the 
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reasoning system to develop new plans through logical analysis, analogical reasoning, 
etc. Many of these ideas are being pursued by other researchers in other contexts. I 
will indicate these in the next section which reviews the related literature. 
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Chapter 15: A Survey of Related Work 

[Waldinger & Levitt, 1973] point out that the first program verification 
methodology was worked out by Von Neumann [Von Neumann, 1963] and that 
validation is as old as software itself. In 1966, McCarthy and Painter 
[McCarthy & Painter, 1966] presented a proof of correctness for a simple expression 
com f iler. Foundational techniques using the notion of a state vector (the vector of 
current values of all program variables) were presented in [McCarthy, 1962a,b, 63]. 
Indeed, the formal definition of Algol [McCarthy, 1964] was influenced by a concern 
for provability. 

However, the modern interest in verification seems to date back to Floyd's 
pioreering work [Floyd, 1967] (independently [Naur, 1966] developed similar ideas). 
In tl is method, flowcharts are annotated by assertions which are believed to hold any 
time control passes through the annotated point of the program. An informal 
verification may be constructed by dividing the flow chart into control paths, showing 
that each assertion is a logical consequence of the earlier assertions and the intervening 
prog jam steps on its path. The pairs of entrance and exit assertions state the I/O 
properties of the program. Normally, the programmer need only supply these 
asser ions and one assertion, called the invariant, for each loop. This notion of 
correctness is called partial correctness, since it does not include a proof that the 
progi am terminates. The assertions are called inductive assertions. 

Floyd also introduced a method for proving termination of programs. This proof 
is co iducted separately from the proof of partial correctness and involves constructing 
a nupping between program variables and a well-founded set, i.e. a partially ordered 
set with no infinite descending chains. If a monotonically decreasing mapping can be 
constructed then the program must terminate. [Manna, 1969] formalized these results 
showing that the partial correctness of the program is equivalent to the satisfiability of 
a statement in first order logic and that total correctness is equivalent to the 
unst i isfiabilitv of a second statement Intuitively, the first statement says that there is 
a set of inductive assertions from which a partial correctness proof can be built; the 
secorjd statement says that there is no set of assertions which would imply that the 
prod am halts with incorrect values. 
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C.A.R. Hoare [Hoare, 1969] extended Floyd's work by showing how it could be 
fit into a formal logical language. Hoare introduced the notation P {A} Q to mean 
that if P is true before program A is executed, then Q will be true after A's 
execution, (if A terminates). Hoare also presented several rules of inference for this 
system such as: 

P -> R. R (A) S. S -> T 


P {A} T 

In later work, Hoare [Hoare & Wirth, 1973] presented an axiomatization of the 
programming language PASCAL using this formalism. The primitives of the language 
are defined by partial correctness formulae which, like those above, state how a 
language construct will transform a predicate. For example, assignment to a simple 
variable is defined by 


p <x <- E) P 
E 

This states that if P holds after x is assigned E, then P with every occurrence of x 
replaced by an occurrence of E is true before the assignment Hoare's techniques 
were taken further in [Dijkstra, 1975, 1976] where Hoare's partial correctness formulae 
are extended to Dijkstra's predicate transformers. Where Hoare would write P {A} R, 
Dijkstra would write P = wp(A,R), indicating that P is the weakest predicate which 
guarantees both that A terminates and that R will hold afterwards. Thus, Dijkstra's 
predicate transformers strengthen Hoare's work to deal with total correctness. 
Dijkstra also used his notions to define a language with limited non-determinism. 
Another extension called the intermittent assertion method {Manna & Waldinger, 1976], 
also allows proofs of total correctness; it uses assertions which are not invariants but 
which must hold at least once (hence the name intermittent assertion). [Pratt, 1976] 
presents foundational work providing a semantic model for these formalisms and a 
logic in which the methods of Floyd, Hoare, Dijkstra, etc. can be compared. A host 
of literature analyzing the theoretical and computational foundations of these methods 
has appeared in recent years such as [Lipton, 1977] and [Jones & Muchnick, 1977] to 
chose two at random. 
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Floyd's method was developed for flow chart programs and uses inductive 
techniques implicitly. [Manna & Pnueli, 1970] generalized Floyd's techniques to handle 
recursive programs as well. Inductive arguments are relied on. Other inductive 
techniques were also developed, including computational induction [Park, 1969], 
recursion induction [McCarthy, 1963] and structural induction [Burstall, 1969]; sub-goal 
induction, a variant of the inductive assertion method, is presented in [Morris & 
Weg ireit, 1977], Structural induction "inducts" on the depth of recursion of the 
prog-am's data structures; computational and recursion induction are inductions on the 
dept i of function calling. Floyd's inductive assertion method is an induction on the 
length of the computation path. These methods are surveyed in [Manna, Ness & 
Vuillemin, 1972] and also in [Reynolds, & Yeh, 1976]. [Manna, 1974] covers a wide 
rang 1 of theoretical issues underlying program verification and related fields. 

Following Floyd and Hoare's seminal papers a literature began to develop in 
whic l various hand proofs of program correctness were presented. These include 
[Hoa e, 1971] and [London, 1970a,b,c 1971]. Attempts to automate the process soon 
followed. The first of these was [King, 1969], a very fast verifier of limited power. 
King s system was coded in assembly language and had built in several special purpose 
features for simplifying expressions and for handling systems of linear inequalities. 

The second system within the Floyd-Hoare framework was PIVOT, implemented 
by Peter Deutsch [Deutsch, 1973]. Pivot verified programs written in a limited 
Algo-like language; it works in a manner more similar to my symbolic interpreter 
than do many of the later systems. PIVOT traversed the program text in forward 
ordei (i.e. it started at the beginning and moved towards the end) and interleaved 
simplification of expressions with interpretation of the program text It also used a 
context mechanism to record the values of variables and the truth value of clauses. 
The context mechanism allowed PIVOT to have an incremental view of the 
comf utation's temporal progression. PIVOT had a fixed sequence of deductive 
techi iques which it employed repeatedly. It worked by refutation, trying to reduce 
the negation of the goal to a contradiction. It was, thus, more like a resolution 
theorem prover than many of the other verification systems since. 

Three further systems followed, inspired largely by the original implementation of 
the Stanford Verifier [Igarashi, et. aL, 10 73} Igarashi, London and Luckham reduced 
Hoars's logical system to a core of ru vhich were deduction complete (Le. anything 
the lull set could deduce, the core could as well) and which, furthermore, could be 
used deterministically. The Stanford group's set of rules was chosen so that there 
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would always be exactly one rule which could be applied at a time. These rules were 
used in a backwards manner to create a series of subgoals for the output assertioa 
For example, if the program were: 

P (A . . . B; x<- E} 0 

there would be exactly one rule whose consequent matches the expression within the 
braces. For example: 

X 

P {A ... B} o 

E 


P {A ... B; x<- £} 0 

These rules are applied repeatedly until the inside of the braces contains an empty 
program. An implication made from the two formulae surrounding the empty braces 
is handed to a theorem prover; if the implication can be proven, the program is 
correct. Originally, the Stanford system used a resolution theorem prover [Allen & 
Luck ham, 1970], but this was replaced by an algebraic and logical reduction system 
implemented by Suzuki [Suzuki, 1975]. Further work on the Stanford verifier includes 
a technique for proving termination [Luckham & Suzuki, 1975] which inserts in each 
loop a ghost" variable to count the number of repetitions. Termination is proved by 
demonstrating an upper bound for the ghost variable. [Luckham & Suzuki ,1976] 
extended the proof rules to include more complex data structures including records, 
arrays and pointers. [Nelson & Oppen, 1978] have added a more powerful and 
efficient simplifier to the Stanford system. 

A second verification system was started at Stanford Research Institute [Elspas, 
Levitt, & Waldinger, 1973] which used a verification condition generator similar to 
that of Igarashi, et al. However, the SRI system was built around a natural 
deduction theorem prover of some power, implemented in the language QA4. QA4 
has a \ ery powerful collection of data types including sets, bags, and tuples built into 
the language which allow the theorem prover to ignore issues like the canonicalization 
of arithmetic expressions. QA4 also provides contexts and backtracking facilities for 
hypothetical reasoning. (Although Doyle's TMS makes these facilities unnecessary in 
REASON, at the time of their incorporation into QA4, they represented a clear step 
forward in theorem proving languages). By using QA4, the SRI group was able to 
build the theorem prover as a set of small QA4 procedures, grouped into clusters. 
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The SRI system is also reported on in [Waldinger & Levitt, 1974]. 

A third system was developed jointly between the Information Sciences Institute 
at LSC and the Automatic Theorem Prover project at the University of Texas [Good, 
Lone on & Bledsoe, 1975]. This system uses a modified version of the Stanford 
verif cation condition generator, a powerful logical and algebraic manipulation package 
called REDUCE [Hearn, 1971] and the theorem prover of [Bledsoe & Bruell, 1973]. 
The theorem prover is a natural deduction system with special heuristics for case 
splitting, interval arithmetic (based on the technique of [Bundy, 1973]), and range 
splitting in quantified statements [Bledsoe, 1971]. The verifier itself was proven 
correct (by hand) in [Ragland, 1973]. 

Two other verification systems of note have been developed; neither of these uses 
the Hoyd-Hoare framework. The Boyer-Moore theorem prover for recursive function 
theoiy [Boyer & Moore, 1975,77] uses structural induction rather than inductive 
assertions; it states both the program and its specifications in Pure LISP, using 
symbolic execution to reduce the expression. Their system contains powerful methods 
for choosing the basis for an induction and for generalizing sub-goals into lemmas. 
The system has proved impressive theorems in recursive function theory; it has also 
verified a fast string searching algorithm and an arithmetic simplifier. 

The other verification system, [Milner, 1972a, b], [Milner & Weyrauch, 1972], is a 
proof checker for Scott's Logic of Computable Functions (LCF) [Scott, 1972} The 
strength of the LCF system is that it operates within a powerful formal logic within 
whic l it is possible to reason about complex procedures which manipulate procedures 
as objects. Lisp programs which we would find difficult to handle within our system 
are 1 andled directly within LCF. The system was implemented as a proof checker to 
assist the human proof constructor. VonHenke has done some work on integrating 
abstract recursive structures in the system [vonHenke, 1975} In later work, [Gordon, 
Milner, et. al., 1978], the system was extended to facilitate the semi-automatic 
generation of proofs and the integration of new strategies and types. 

Of the systems I have mentioned so far, the one most similar to REASON is 
Peter Deutsch's PIVOT. Both systems use symbolic interpretation in a forward 
direc ion and interleave simplification with evaluation. The other Floyd-Hoare systems 
use verification condition generators which reduce the entire computation history to a 
single first order implication. A symbolic evaluation system quite similar to REASON 
and Deutsch's PIVOT is described in [Hantler & King, 1976} Other symbolic 
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execution systems have been used in a program testing (as opposed to verification) 
environment to form symbolic expressions for the values of program variables. Typical 
of these is [King, 1976], [Clarke, 1976] and [Hovvden, 1977,78]. [Balzer, 1978] uses a 
weak form of symbolic evaluation to fill in the omitted details of an imprecise 
program specification. [Yonezawa, 1977] describes a system quite similar to mine 
which is based on that in [Hewitt & Smith, 1975]. However, his system was never 
implemented. 

REASON views programs more dynamically than do many of these other 
systems. During its normal reasoning it moves assertions backward and forward 
through the situations, reflecting the dynamic propagation of facts through the 
situations of the program. In addition, when used within the recognition system, 
REASON takes an even more dynamic view, expanding the program's temporal 
behavior and resegmenting this into logical units. This process oriented view more 
closely resembles the recent theoretical of Pratt on process logic [Pratt, 1978] and the 
work of Pnueli [Pnueli, 1977] on temporal logics suitable for describing 
non-terminating programs like operating systems. 
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Section 15.1* Newer Areas of Verification ResearcH 



tesizing Loop Invariants 

There are several areas of current research on verification systems which I would 
o mention before going on to program understanding research more similar to my 
The first of these is the problem of synthesizing loop invariants. The 

-Moore system does not need to form loop invariants, but rather uses structural 
tion on the data structures to achieve the same effect It has a number of 

sties for choosing which data structure to "induct" on, and works completely 

laticaiiy. The Floyd-Hoare systems, however, require some other process, human 
achine, to generate the inductive assertions. Although, [Dijkstra, 1976] argues 
human programmers ought to generate loop assertions as the first step of 
ling their programs, many researchers have found this cumbersome and would 
■ to have an automated loop invariant synthesizer. 

Early research in this area includes [Cooper, 1971], [Elspas, 1974] 

is, et. al., 1972] in which recurrence relations are generated through use of a 
loop counter. [Wegbreit, 1973,74] introduced a number of heuristic techniques 
involve strengthening and weakening of assertions. Typically the original 

ion is one known to hold immediately after the loop's exit (this is easily 
a ted by the normal VCG procedures) or immediately before entrance to the loop. 
;thening heuristics include dropping a clause from a disjunction or adding one to 
a conjunction. Wegbreit's techniques were implemented in [German, 1974] and 
red on in [German & Wegbreit, 1975]. [Katz & Manna, 1973,76] have developed 
r techniques including some for handling arrays and for strengthening a partially 
:t loop invariant. [Greif & Waldinger, 1974] have also studied some techniques 

in ttyjs area. 

\ 

| More recent work in automatic synthesis of invariants have included 
un, 1975], implementation efforts such as those of [Dershowitz & Manna, 1977] 
[Moriconi, 1974], [Cousot & Halbwachs, 1978] presents a method for 
mtically deriving linear inequalities among the variables of loop; these inequalities 
be used as invariants. [Basu & Misra, 1976] have studied some classes of 
uns such as accumulation loops in which the loop invariant is especially easy to 
>p automatically. Their work resembles to a small degree [Waters, 1978] work 
op analysis, in that both look for standard patterns within a loop and build a 
ption of the loop based upon known properties of these standard patterns. 
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REASON currently relies exclusively on Waters' techniques plus more advanced 

recognition techniques being worked on in [Rich, 1978} I do not yet know whether 
this will be completely sufficient, or whether I will have to include some of the 
heuristic techniques mentioned above. Probably, REASON will only use such 

techniques as a last resort strategy. 

Abstraction Techniques 

Another major area of ongoing research is the development of abstraction 

techniques which allow the program and its proof to be structured into layers of 
smaller procedures. Various approaches have been taken. [Hoare & Wirth, 1973] in 
their axiomatization of PASCAL include a procedure call rule which is the basis for 
any form of procedural abstraction. Various technical difficulties with the rule have 
been discussed in [Cartwright & Oppen, 1978] and [Guttag, et al, 1977} However 
the ability to refer to a procedure by its specification is only the first step in most 
abstraction techniques. 

Frequently, abstraction techniques have been concerned with specifying, 
implementing, and proving the correctness of abstract data structures. [Hoare, 1972] 
introduces a method for proving the correctness of a data structure implementation, 
using the notion of an abstraction function to map between the variable of the 
concrete space and the variables of the abstract space. [Parnas, 1972] develops a 
method for hierarchically specifying a system in which each level of procedure is built 
from modules at a lower level. Modules consist of two types of procedures: O 
procedures which are allowed to have side effects and V procedures which cannot 
Thus, the values of the various V functions characterize the module's state, and the O 
procedures can be specified in terms of their effect on the values of the V functions. 
This is quite similar to our method of specifying side effects and has been used in 
[Robinson & Levitt, 1977} 

Some newer languages such as Alphard [Wulf, et al., 1976] and CLU 
[Liskov, et. al., 1977] have extensive facilities for grouping procedures together into a 
data abstraction" with each procedure representing some of the behavioral capabilities 
of the abstract datum. The procedures of the data abstraction share access to the 
concrete representation, while procedures outside are, in general, denied such access. 
Motivated by these languages, a specification technique, called data algebras, has been 
developed in [Guttag, 1975] and [Zilles, 1975} In this technique the data abstraction 
is specified by axioms containing equations interrelating the behavior of the functions 
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cont; ined in the data abstraction. Verification consists of showing that each module 
in tli? "cluster" preserves each of the axioms. An inductive argument then shows that 
the i xioms are invariants of the cluster since only the modules of the cluster may act 
on objects of the abstract type. This approach is quite different than those we use; 
[Yomzawa, 1977] presents an argument for techniques more similar to ours. 
[Lisl: )v Sc Berzins, 1977] have written a survey of data specification techniques. 

Sid<! Effect on Complex Data Structures 

A closely related area of research has dealt with the problems of side effects on 
complex and shared data structures. [Oppen, 1975] presents an axiom system for 
reasoiing about Directed Graphs and derived a computability result for this system. 
[Yeliowitz & Duncan, 1978] also work with the DiGraph model, but develop a much 
more succinct formalism. 

Suzuki, 1975] develops axioms for the complex data structures allowed in 
PASCAL. In this system each data type is made to appear to be an array, indexed 
by pointers of the appropriate data type. This is possible since in PASCAL a pointer 

variable may only reference objects of a single type. Suzuki requires a special 

notat on for predicates which refers to a recursive data type; they must include 

symb }ls to refer to all the data types involved in the definition. Supposing one wished 
to hr ve a predicate stating a well formedness criterion for lists of pairs. This would 
have to stated as 

(Well-formed List-of-Pair-1 P#list P#Pair) 

"'hen the last two symbols represent the pseudo-arrays of lists and pairs. If a side 
effecl is performed on any list or pair, this predicate will be updated by changing one 
of th ? last two symbols in a manner analogous to the standard array rule. Although 
logically sound, the system produces large expressions whose intuitive meaning is, at 
best, unclear. In large interrelated systems, the expressions might well become 
intractable. Suzuki s technique can be viewed as a special case of my 

potential-dependency network, in which a very course filter is used to decide if an 
assertion is threatened by a side effect Whereas REASON filters for specific types of 
side < ffects to a particular data type, Suzuki’s system filters for any side effect; thus, 
his system will produce unduly complicated expressions. 
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[Yonezawa, 1977] uses a formalism which, except for the use of the TMS, is 
quite a bit like mine; this is hardly accidental since we shared an office for 2 years 
and both worked with Carl Hewitt His thesis describes a system which uses the 
situational calculus to reason about the situational transformation brought about by a 
side effect. However, Yonezawa's later interests moved more towards a formalism for 
reasoning about parallel procedures and synchronization; his system was never 
implemented. 
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Section 15.2: Apprentice-Like Systems 

There has been some other research which includes one or another of the 

characteristics of the programmer's apprentice project i will briefly review two 

cate£ )ries of these: The first involves some attempt o support the programmer in an 
interactive design and evolution environment; The second involves some attempt to 
catalogue standard programming knowledge, 

Systjcms for Evolutionary Design 

VIost developed among the systems which support interactive design and 

modification is the system of [Moriconi, 1977]. This system, called SID, is integrated 
into the University of Texas/ISI verification system of 
[Gock , London & Bledsoe, 1975]. The new feature of this system is an interface 
module which analyzes proofs constructed by the theorem prover to determine the 
dependencies between the verification conditions. These are then represented in a 

simpllji network. The verification conditions are also analyzed so that their dependence 
on pr rticular lines of code is recorded in the data base. When program modifications 
are (proposed, the network is examined to see whether any logical link is affected. 
This! Is quite similar to the apprentice's purpose links. However, if some dependency is 
affedied, both the verification condition generator and the theorem prover must be 
called to completely recreate the proof for the modified section of code. Thus, the 
systejn is less incremental in its analysis than is REASON which uses the Truth 
Maiijr enance System to reuse as much of the original reasoning as possible. 

\nother project of a similar nature is that of [Dershowitz & Manna, 1977] and 
[Kat|z & Manna, 1976]. In the first of these, analogies between the new and old 
versions of the program specs are used to generate loop invariants for the new code. 
In thi second, a table of dependencies between loop invariants is maintained to aid in 
the | analysis of modifications. Both of these system seem less developed than 
Morjtoni's. The Dershowitz and Manna paper has a brief discussion of the use of 
schem ata to capture some programming generalities, but none of these systems have 
our Hnphasis on cataloging programming knowledge. 
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Several systems have, however, attempted to take a knowledge based approach. 
[Schwartz, 1977] proposes to build a set of root programs representing basic 
programming techniques and a set of correctness preserving combination rules. 
However, this process is to take place in a strictly hierarchical manner; the work is 
also intimately tied to the language SETL, in contrast to our attempt to remain 
language independent. 

[Gerhart, 1975a] proposes to catalogue programming knowledge in the form of 
schemata which serve as syntactic templates. Programming knowledge and proof rules 
are attached to each template, forming a catalogue of programming knowledge. I feel 
that this representation is too low level and language dependent, even though some 
generality is regained through use of correctness preserving transformations 

[Gerhart, 1975b]. [Darlington & Burstall, 1973] have also studied the use of 
transformations. 

An early attempt to catalogue programming knowledge is found in 

[Ruth, 1973,76a]. Ruth represented algorithms as grammar's for a parser using an 
ATN-like formalism. Each grammar can parse several programs representing different 
implementations (including some with standard bugs) of the same algorithm. The 
system was developed to parse the programs of beginning students and lacks several 
features which seem important in the more complex domains which concern me. The 
ATN-like formalism seems overly syntactic and cumbersome for the representation of 
the wide range of programming knowledge which I desire to capture. Also, since the 

formalism has no means of stating the intrinsic behavior of sub-segments, it has no 

ability to represent the purposeful nature of the interconnections between modules. 
Later work, [Ruth, 1976b, c] develops an expert system for inventory data bases with 
extensive knowledge of file and record organization. 

The knowledge based system most similar in approach to the apprentice system is 
the PSI system of [Green, et al., 1976,77] (in particular the PECOS sub-system 
developed in [Barstow, 77]). PECOS is a set of refinement rules for program synthesis 
representing a broad range of knowledge about sets, mappings, tuples, arrays, etc. 
arranged to capture as much general knowledge as possible. Although the system has 
some implementation and representational problems (it has neither a deductive system, 
nor a clear notion of data flow), it does seem to capture a reasonable segment of the 
knowledge of the expert programmer in a natural manner. Efficiency knowledge is 
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represented in another sub-system called LIBRA, [Kant, 1977]. The entire PSI system 
has teen capable of synthesizing the code for a simple version of a learning program. 

A different type of synthesis system has been developed by 
[Map : 1 a & Waldinger, 1977] in which far more reliance is placed on deductive 
capajt ilities. Their system is capable of synthesizing a program to satisfy a given set 
of ifi -jut-output specifications. It has rules for loop, recursion, and test formation as 
well; ts a method for handling destructive interference between simultaneous sub-goals. 
AnoHer recent knowledge based system is the SAFE system of [Balzer, et aL, 1977] 
whicjl takes informal program specifications and attempts to translate these into a 
precise formal description from which a program may be synthesized. 

An excellent treatment of many aspects of program verification and synthesis can 
be fbund in [Manna & Waldinger, 1978]. 
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Section 15.3: Dependency Based Reasoning 

This thesis has been interlaced with many references to the works of my close 
colleagues at the MIT AI lab. My approach to developing the deductive machinery of 
REASON has been influenced heavily by the AI Lab's intellectual atmosphere. 
Dependency based systems like [Stallman & Sussman, 1977] and [Doyle, 1978] have 
strongly influenced the redesign of REASON. Another dependency based system 
which has influence my thought is [London, 1977]. [Doyle, 78] surveys much of the 
current literature on dependency based systems. 

The idea of explicit representation of control as a stepping stone to introspective 
systems is also heavily influenced by [Doyle, 1978] as well as by 
[DeKleer, et. al., 1977} [McDermott, 1976] introduced the task network formalism 
which he developed considerably further in his NASL system than I have yet done in 
REASON. The idea of this form of organization was called to my attention by Doyle 
(private communication). [Davis 1976] uses a weak form of self reflection in a 
backward chaining system. 

A strong influence on my approach to handling side effects has been the 
considerable AI literature on the frame problem. [McCarthy & Hayes, 1969] and 
[Hayes, 1971 a, b] are good introductions to this issue. [Raphael, 1970] surveys the 
known techniques for handling the problem. 

REASON'S entire design is shaped by the central importance given to plans 
within the apprentice system. HACKER [Sussman, 1975] introduced many of the 
ideas which helped us develop the plan formalism. Other ideas such as the 
categorization of plans into particular types first appeared in [Goldstein, 1974} The 
plan formalism as we now use it first appeared in [Rich & Shrobe, 1976} Its current 
form was heavily influenced by Waters work in [Waters, 1977} [Sacerdoti, 1975,75a] 
developed a similar formalism as part of a plan compilation system. Johan deKleer's 
[deKleer, 1976,77] work on understanding electronic circuits and Allen Brown's 
[Brown, 1977] work on isolating failures in a circuit have also influence the plan 
formalism. 
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[Miller & Goldstein, 1976a, b, 77] have been developing a notion of plan for use in 
tutoring sessions. They have catalogued very general problem solving strategies, whose 
they represent in an ATN-Iike grammar. The grammar is used to parse the 
protocol of a student's coding sessions, so that the computer tutor can provide advise. 
A s inilar methodology is used in [Genesereth, 1978] to help experts using the 
MAjCSYMA symbolic manipulation system. However, in this case the assumption is 
that) the expert has correctly formulated a plan, but has based his plan on faulty 
knowledge of the MACSYMA facilities. Genesereth's system functions as a 
MAjCSYMA consultant, not a tutor. 

The earliest mention of a system like the programmer's apprentice is in 
[Floyd, 1971], although verification and related techniques were not yet well enough 
oped to do much with the proposal. The pressures of engineering large Artificial 
igence systems led to another exploration of the idea in [Winograd, 1973]. 
itt & Smith, 1975] developed the idea further within the framework of the 
PLASMA programming language. Both Hewitt and Smith encouraged me and 
prov 


Intejl 
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ped some initial insights. 


I began this thesis by placing it within the context of a developing set of 
techniques which I hope will help develop truly self-conscious systems. This document 
is net intended to answer many of the difficult problems which will lie on that course, 
but only to develop some technical foundations in program understanding which will 
help those more bold than I. Minsky [Minsky, 1968] and McCarthy's 
[McCarthy, 1968] ideas of a decade ago, still lie ahead of us, waiting for solution. 
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